-
Notifications
You must be signed in to change notification settings - Fork 435
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
Struct unmarshmaling and more #29
base: master
Are you sure you want to change the base?
Conversation
This looks really cool. Thanks for keeping the offset-computing code separate so as to not slow down the simpler |
What if you made a wrapper around the core functions for a more user-friendly experience? E.g.:
The refs returned by The idea is to hide the need for slicing the data and calling Get() for each offset lookup inside the API. Just thinking out loud, not sure this is actually a good idea :). |
Yeah, this could be a good idea, and we can hide caching inside. |
Well actually syntax above is not supported, as Go do not support variable list of returned arguments |
Doh, you're right, I guess I meant |
I want to test this soon with some big data-sets and will supply the results here. Just by mere conversion from Update: Maybe there's also focus points here. These are the hotspots on my
|
@buger Is work continuing on this effort? |
Have you considered some variation on:
|
This is ongoing PR but i wanted to show what i'm working on right now.
There is 2 major changes here:
encoding/json
works (use feature above)I added new API function
KeyOffset
which returns offsets in base data structure for all keys at once, so it can do less reads.Here is example taken from benchmark:
As you can see from UX perspective it looks way worse, but it can give significant speedup, see benchmarks below. As future improvement i wanted implement iterator like access, similar to
ArrayEach
which reduce number of reads even more.Based on feature above, i implemented basic version of Unmarshaler, you can check the code and bechmarks (looks not bad, considering that it does not use code generation). As unique feature i plan add support for nested keys, so you can specify them like:
Here is initial benchmarks:
KeyOffsets
can be optimized much more in my view.