-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Benchmark with GB/s columns #33
Conversation
I think that @croteaucarine is getting > 1 GB/s speeds but she is using a different approach. https://github.com/croteaucarine/simdjson_node_objectwrap |
Hi @nojvek, it is possible that there is still a lot of overhead. |
Thanks for your work, @nojvek! |
It seems std::move is having a significant perf cost. I wonder if there is a way to work around it.
I tried this and get > 1GB/s (almost double what I got before). I know ^ is not really valid code as it will give SIGSERV errors, but just wanted to try something surgical.
|
I see, that makes a lot of sense! When you do it, is it the same performance of the |
Seems like the overhead adds up for small files more than bigger files. I assume that's because benchmark runs more ops for smaller files than for bigger files. |
Not only that, it seems to be the cost of doing |
Ping @jkeiser : you may want to check these numbers and the discussion on the cost of std::move. |
I'm wondering if it's the new rather than the move? There should only be 2 pointers to move here, I would have expected it literally to be 1-2 load/stores. We could try a few things:
@lemire all of this makes a reasonable case for the document to be rooted in a single pointer. Bindings are far more likely to naively support storing one raw pointer than two. |
By creating an empty document
I get:
So, unless I got something wrong, it is not the |
I took a look at this problem today again and is really the |
@luizperes I made a lot of research and tests to find out that the conversion between C++ Objects and Napi Objects really takes a lot of time and must be avoided as much as possible. Event passing the JSON doc as string and converting it to Napi::String before calling the simdjson parser has a considerable impact on performances. |
@luizperes maybe the right thing to do (at least for now) is to return to the old way of using |
Thanks for your help @jkeiser! Yeah, as I mentioned on #36, it seems that this approach did the opposite (it seems a little more costly). As for the error margin, I don't think I understand what you mean that "some numbers are up and some are down", could you explain it a little better? #35 seems interesting :) |
In my results there, the PR actually makes some files faster, and others slower. I was blaming error margin and jitter in the results because I couldn't explain it--everything in the change should be fixed per-document overhead-- but after running it a few more times, it might be real. |
Fixes #21
@lemire / @luizperes I am not seeing the > 1GB/s results though. Not sure what the nodejs overhead is, or whether my macbook pro from 2018 is just too slow.