You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
https://crrev.com/c/2291558/11 is an experimental change to the Chromium web browser to use Wuffs' Eisel implementation instead of google/double-conversion. Parsing various JSON files sped up by between 1.01x and 1.46x. That's the total time to parse a JSON file (and allocate the resultant node tree), not just the net time spent in StringToDouble or its equivalent. Obviously, the speed-up is more dramatic for number-ful JSON (as opposed to string-ful JSON).
Perhaps this library should consider adopting the same algorithm.
The text was updated successfully, but these errors were encountered:
The string->double conversion was never optimized in this library. It should have a decent speed, but there are definitely low hanging fruits.
Unfortunately, I currently don't have time to improve the library (as long as it yields the correct results).
For example, the library could/should also switch to Ryu (https://github.com/ulfjack/ryu) which should make it faster and avoid the pesky corner cases described in #83.
Closing, to avoid giving the impression that someone is working on it.
If I find the time to work on it, I will reopen.
https://lemire.me/blog/2020/03/10/fast-float-parsing-in-practice/ briefly describes a new StringToDouble algorithm by Michael Eisel. It claims a 2.64x speed-up versus this library,
github.com/google/double-conversion
.The
github.com/google/wuffs
repo contains a re-implementation of that Eisel algorithm:kCachedPowers
table atdouble-conversion/double-conversion/cached-powers.cc
Line 46 in b1d531b
https://crrev.com/c/2291558/11 is an experimental change to the Chromium web browser to use Wuffs' Eisel implementation instead of
google/double-conversion
. Parsing various JSON files sped up by between 1.01x and 1.46x. That's the total time to parse a JSON file (and allocate the resultant node tree), not just the net time spent inStringToDouble
or its equivalent. Obviously, the speed-up is more dramatic for number-ful JSON (as opposed to string-ful JSON).Perhaps this library should consider adopting the same algorithm.
The text was updated successfully, but these errors were encountered: