You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Each node in the radix tries should have at most 10 children. In this scenario, a hash map often adds overhead compared to using a simple 10-element array. For example, i was able to reduce the runtime of the Zig implementation from 67 to 42 ms on my machine, and i suspect similar improvements are possible for the other compiled languages.
The text was updated successfully, but these errors were encountered:
Agreed, but if we change one implementation, the similar changes should be implemented for all other tests. Also please note that we don't have a goal to create the fastest prime numbers generator, but rather to compare performance of the similar functionality between different languages. It's quite tough and unfair task already, and micro-optimizations could make it even more tougher and more unfair. For example, PHP arrays are internally all hashmaps regardless of how they used (as vectors or as associative arrays), so the change like that won't affect its performance.
Nevertheless, I'd accept the PR with changes (if all tests are addressed).
Each node in the radix tries should have at most 10 children. In this scenario, a hash map often adds overhead compared to using a simple 10-element array. For example, i was able to reduce the runtime of the Zig implementation from 67 to 42 ms on my machine, and i suspect similar improvements are possible for the other compiled languages.
The text was updated successfully, but these errors were encountered: