-
Notifications
You must be signed in to change notification settings - Fork 138
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
Rewriting the parser using stacks #25
base: master
Are you sure you want to change the base?
Conversation
Codecov Report
@@ Coverage Diff @@
## master #25 +/- ##
==========================================
- Coverage 93.11% 92.88% -0.24%
==========================================
Files 9 9
Lines 1046 1124 +78
==========================================
+ Hits 974 1044 +70
- Misses 49 55 +6
- Partials 23 25 +2
Continue to review full report at Codecov.
|
After resuing the parser, here are the new benchmark results:
Now it's much closer to the original performance. Here is the CPU profile:
|
@valyala can this be merged as well? |
This is great idea, since it requires less RAM when parsing JSON structs with non-constant structure, but it slows down parsing a bit. I tried playing with this PR in the mem-optimize2 branch, but it isn't ready for merging into master. |
Any update for this PR? |
After figuring out that the benchmark was defective, I created a new parser using the technique mentioned in #24 .
The benchmark results without
benchPool
, which should be closer to the real performance:fastjson
was even slower thenstdjson
despite claimed 15x improvement.After rewriting the parser using stacks, the results are:
fastjson
is still slower than original, but now it is really faster thanstdjson
, rather than.fake results obtained by parsing the exact same json value again and again.There is no need to reuse
Parser
now since it is always reset beforeParse
. There may still room for improvement by reusingParser
, worth investigating later.