Did you benchmark if a the binary lockfile actually makes any appreciable difference for execution time?
Considering the speed with which a fast parser can gobble up JSON I'm somewhat skeptical that this would be relevant for common operations.
Considering the speed with which a fast parser can gobble up JSON I'm somewhat skeptical that this would be relevant for common operations.
Yes he did
I don't see it either. Perf data that shows that was the issue.
https://news.ycombinator.com/item?id=31993429
Of course, I can't say for sure that he looked at the fastest possible way to parse json here, but my intuition would be that if he didn't, it's because he had an educated guess that it'd still be slower.
It's just comparison of execution times of several different package manager.
Better would be parsing JSON vs binary in Bun.
If you were dealing with a multi-gigabyte lock file then it would be a different matter but frankly I agree with their point that parsing a lock file which is only a few KB shouldn’t be a differentiator (and if it is, then the JSON parser is the issue, and fixing that should be the priority rather than changing to a binary format).
Moreover the earlier comment about lock files needing to be human readable is correct. Being able to read, diff and edit them is absolutely a feature worth preserving even if it costs you a fraction of a second in execution time.
You mean a few MB? NPM projects typically have thousands of dependencies. A 10MB lock file wouldn't be atypical and parse time for a 10MB JSON file can absolutely be significant. Especially if you have to do it multiple times.
> Being able to read, diff and edit them is absolutely a feature worth preserving even if it costs you a fraction of a second in execution time.
You can read and edit a SQLite file way easier than a huge JSON file.