Changes HashMap to use aHash instead, giving a performance boost.#9391
Changes HashMap to use aHash instead, giving a performance boost.#9391fdncred merged 3 commits intonushell:mainfrom
Conversation
|
I'm good with going this direction but I wonder how you arrived at aHash? I mean, how do we know it's the fastest? Could there perhaps be faster ones? |
I had used it previously so i wanted to test if it improved performance, as far as iknow ahash does not lock itself to a specific algorithm so it always uses the fastest one available, it is possible faster ones, but ahash had drop in replacments for the standard library making it easy drop and replace. edit: maybe there exist faster alternative also depending on if we are okay with the hasher not being DOS resistant. |
|
Don't get why the typos gets triggered by this? |
|
it tells you how it's a typo and how to rename it |
Warning: "reuseable" should be "reusable". Just send in another commit with this change and it should pass... |
|
Thank you kindly for investigating this ! Great work 👍 We are going to need to analyze further... For starters I downloaded your branch and built nushell... And I am seeing about 5 - 10ms speedup... This tells me that the benchmarking code may not be the best way to measure the effect of this change. I would be curious to know what you are seeing on your computer as far as startup times Thanks --- lets investigate further and see what we come up with... |
|
Here are my results in a side by side comparison of the nushell main branch versus the ahash branch. https://github.com/stormasm/nunotes/blob/main/ahash.md In order for me to better understand this stuff can you please create a similar table for me... Run the nushell main branch parser_benchmarks on your machine. Thank you ! |
|
Just to jump in. Here's me running cargo bench on my m1mac
|
|
related to - bdb09a9 - [this job](https://github.com/nushell/nushell/actions/runs/5224369668/jobs/9432486180?pr=9392) from #9392 - [this job](https://github.com/nushell/nushell/actions/runs/5222835000/jobs/9428854834?pr=9391) from #9391 # Description this PR tries to fix the typo reported in these very recent PRs
📯 📯 little annoucementthe Typos CI job is failing in this PR. in this PR, you can either
|
|
I'm about ready to land this to see how it goes, but I'd like to have it tested on Windows first. Windows is weird and may behave badly. If someone gets a chance to try it, please post your timings. |
@fdncred I am not sure why we are landing this now... I ran my tests again this morning just to be sure... @FilipAndersson245 in two of his ahash tests is causing a slowdown... And my benchmark tests show a slowdown... I would feel more comfortable landing this if we had a few other folks run the same tests As well as look at their startup times / I am not seeing any changes on startup times... |
|
@stormasm it would be good if you could post all 6 of your timings here so we can gather results consistently. I have 6 of 6 improvements on my mac m1 |
I will run them now and post... |
|
Apple M1 Pro with 16G of memory
Lets land it ! 😄 |
|
i'm building in windows now to see what it does. |
|
Windows
|
|
the revert button creating a commit right away without confirmation is an interesting feature 😅 nothing changed here, no worries 👀 |
This PR reverts #9391 We try not to revert PRs like this, though after discussion with the Nushell team, we decided to revert this one. The main reason is that Nushell, as a codebase, isn't ready for these kinds of optimisations. It's in the part of the development cycle where our main focus should be on improving the algorithms inside of Nushell itself. Once we have matured our algorithms, then we can look for opportunities to switch out technologies we're using for alternate forms. Much of Nushell still has lots of opportunities for tuning the codebase, paying down technical debt, and making the codebase generally cleaner and more robust. This should be the focus. Performance improvements should flow out of that work. Said another, optimisation that isn't part of tuning the codebase is premature at this stage. We need to focus on doing the hard work of making the engine, parser, etc better. # User-Facing Changes Reverts the HashMap -> ahash change. cc @FilipAndersson245
Description
see #9390
using
ahashinstead of the default hasher. this will not affect compile time as we where already buildingahash.User-Facing Changes
Tests + Formatting
After Submitting