Multi-threaded Optimizations and a life time of lifetimes

The project is now multi-threaded, there is no more acync code, and there are way fewer lifetimes. I can’t wait to show you all of it!

Taking our time

When I started 3 hours and 44 minutes ago (this is the most amount of coding time I’ve added in a devlog this project!) I tested the speed of the program using the word “anagram”, set to give the top 5 results, I got the speeds: 6314, 5514, and 5488 milliseconds, (from input of anagram to end of program) that’s about 5.5 seconds! That is not very fast, at all.

My Client

The first optimization I implemented is the use (or reuse) of a Client when requesting definitions from the web. A Client is like a connection to the internet (I think). And every time I got a word’s definition, I created a new Client. (You could imagine how inefficient that can get)
Moving over to reuse a Client was very easy (compared to what’s next )
After this change, anagram returned 4332, 3944, and 4038 milliseconds; about 4 seconds, getting better!

My Client requested multiple threads

Next I made each search for a definition run on a separate thread. Implementing this wasn’t too bad. I did have some trouble with lifetimes but a few .clone()s patched up those errors! But, when the code ran, nothing happened. After panting plenty println!()s I found out that the threads weren’t running, at all . I came to the conclusion that the threads weren’t running because they were using acync closures, and everything acync in rust in lazy and needs to be told to ran. After getting frustrated with tokio I switched the acync part of the acync function with it’s blocking equivalent and everything worked! And with that, I didn’t need tokio anymore ¯\_(ツ)_/¯.
This change returned 3628, 3659, and 3982 milliseconds; about 3.5 seconds, good.

My teacher never thought me how to read a dictionary.

Lastly, I decided to make the code that checks every word against the input word, you guessed it, I’m tired multi-threaded!
This is where lifetimes decided to step in .
(in 2 secs: a reference (ref or &) points to an owned value; so if the owned value 💥, the ref . To stop this, lifetimes say: “just don’t 💥 when there’s a ref (+ some 🪄 so things aren’t easy))
I made the code that splits dictionary searching into multiple jobs, easy.
Than, I tried to make the the system run on multi-threaded, not easy.
After fighting &str for too long I finally decided to just turn all the interrupting &strs into Strings (making the values owned; owned values have no lifetimes (I mean, well…)).
The results after all that are 1769, 1666, and 1665 milliseconds; a little over 1.5 seconds, this is very good!

4 paragraphs, 3 improvements, 2 seconds to run, 1 week to launch.

That was a wild ride! I hope you enjoyed! I do have some after thoughts if you would like to continue reading:
When running with run --release, “anagram” took 800 milliseconds, which I consider fast enough. I do have an idea for something that could make the app run even faster, but I’ll add it if I feel like it.
And I am thinking of shipping within the coming 7 days (maybe, sooner).

Bye!!!