Why is Mojo's dictionary slower (!) than Python's?

Seriously, I don't know why. Leave a comment with feedback on my Mojo script.

Take a look at my Mojo script here:

And here's my Python script:

Here's the Mojo language:

BTW: I used the Elgato Wave 3 microphone in this video:

Here's a follow-up video in which a hand-written hashmapdict in Mojo (thanks to Maxim Zaks!) that is faster than Python's dictionary:

#mojolang #python

[hyperplano]

In the discord channel I read the current dictionary implementation is not optimized. It's been included to allow developers to experiment more with the language, but it will be optimized in future releases.

[brendanhansknecht]

Python actually has a realy optimized dictionary for its constraints (taking untyped keys and values). Mojo will catch up (and should surpass due to static types), but the current dict is new and mostly unoptimized.

Also, this should be memory bound instead of compute bound so even in the long term, I would not expect much of a difference.

[androth]

my guess would be that the mojo implementation is a quick lazy thing just to get maps in, while python uses a C implementation.

[svenmasche]

lmao up until minute 9 i was expecting that you were going to explain it ^^

[murithiedwin]

Mojo official benchmark with python performance needs a comprehensive "mojo feature to python feature" comparison benchmark...

We would like then to see where the 35, 000X speed up claim came from...

[sillybuttons]

The script does exercise item lookup, looping etc. So seems like a pretty valid comparison. Maybe try the collections.Counter if it's implemented in mojo?

[indibarsarkar]

Please try splitting the data in half and assigning each halves to a dictionary. Then measure the time taken to copy or interchange elements from one dictionary to another. Maybe the problem is in the file management and not in dictionary!!

[jinsongli]

my test with the List also shows mojo is slower than python, not sure if I did anything wrong.

[cmdlp]

Maybe in Mojo the Strings are copied and reallocated as new objects, maybe because of the different StringKey type, or maybe (I am not as familiar with Mojo) because Dict stores and owns an own instance of the string, similar to as in C++. There the string and the memory associated with the string is "owned" by e.g. the unordered_map. Maybe you should retry measuring the time, now inserting floating point numbers for examples, that might not be allocated in Mojo.

[pe]

Sorry, but the answer is mostly: It does simply not make sense to do benchmark comparisons with a language or tool under development. Mojo is under development. It is not at all astounding, what you found out. To me it is more astounding that you are surprised.
Performance is always about details! Simple expectations like x is faster than y fail VERY often when measured.
Take the various steps to make Python faster we absolved in the last decade and more: For exampe- In Python 3.11 at first JIT compiling was added. You can fasten something up, but it is not a nobrainer, and further optimizations are needed and will come.
I believe Mojo will do a good job finally. But be a bit more patient.
Especially Mojo will shine in optimizing for new hardware architectures.
If you just want fast Python, use Numba or Nuitka..