Closed lukas8219 closed 3 days ago
Updates:
Finally got some time to run it on a non-virtualized environment. Just ran the same test on GCP using Linux ebpf-playground 5.15.0-1060-gcp #68~20.04.1-Ubuntu SMP Wed May 1 14:35:27 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
And as expected, performance wasn't a huge deal.
Noticed a small increase of 2 seconds between approaches.
@gireeshpunathil Would you consider this a NO-GO?
@gireeshpunathil Any updates here?
@lukas8219 - thanks for the ping. apologies, I am stuck with multiple high priority items this month. I need one or two weeks more,
@lukas8219 - could you pls squash all the commits into one?
@gireeshpunathil Only those with write access to this repository can merge pull requests.
Or do you mean squash all commits locally and force-push a single commit?
yes - the second (squash everything locally into one and force push)
@gireeshpunathil Done
thanks @lukas8219 for the contribution! much appreciated!
Fixes https://github.com/ibmruntimes/yieldable-json/issues/36
Diagnosis:
node --prof parse-text.js
node --prof-process <file.name> >> benchmark.txt
I've encapsulated the possible aggressors into
processOne
,processTwo
functions so the profiler could gather more precise information... and re-run the same diagnosis steps - which lead me to this benchmark results bench-indexOf.txtIt's pretty clear that the main aggressor was
while loop
that had synchronousindexOf
operations, causing performance hits in long strings.Solution:
Split the
indexOf
method into it's own generator-style - yielding at each N sized chunk.Results:
Using the same script shared by the issue author, event-loop was unblocked. But there was some performance hit, expected due to generators yielding.
Using
master
code: 1.92s user 3.03s system 109% cpu 4.534 totalUsing
new code
: 5.17s user 3.95s system 134% cpu 6.785 total