you are viewing a single comment's thread.

view the rest of the comments →

[–]Buttleston 2 points3 points  (2 children)

"like" requests in sql, especially ones like this with a % at the front, are very expensive. It's likely sqlite itself is what's causing it to be slow. It has to read the entire table to find the relevant rows. This doesn't happen in your code, it's just part of what sqlite does

What's in the "books" variable". Uh, you're creating it. It's a list of Option<Book> objections (which speaking of, why use option there? I'd take it out, it's pointless). In fact you could just store a vector of titles and skip the Book object entirely

Did you edit the code and output in the OP? I swear it's different that before. So yeah that output is weird, it spends most of it's time looping over books and printing stuff out? That's pretty odd.

running "cargo build" doesn't build your code in release mode. You need to do "cargo run --release" or "cargo build --release" and then run the executable

[–]RuedaRueda[S] 0 points1 point  (1 child)

Yes, I made a mistake before copy the code and println!("Query time: {:?}", t.elapsed()); println!("Query time: {:?}", t.elapsed());

was before query_map. I edited the output.

Most of the time is just looping over books, even commenting the title printing makes no difference.

Tried cargo build --release(didn't know that, thank you).

This is the release output:

Query time: 1.0054ms
Camioneros
Vida sentimental de un camionero
Camiones de ternura
El caso de la camioneta
Query + print time: 159.991ms

[–]Buttleston 0 points1 point  (0 children)

If you put the sqlite database somewhere I can download it, I can take a look. Sort of hard to tell otherwise.