3 ms·

In my experience, doing this in C++, disabling checks is maybe 5-20%, more often around 10%, not really worth doing outside benchmarks. When it's already going

In my experience, doing this in C++, disabling checks is maybe 5-20%, more often around 10%, not really worth doing outside benchmarks. When it's already going at GB/s, just do the checks and use the types to get more checks. Allocations, have been a huge win. Parsing to a vector in many of the JSON benchmarks benefitted from reserving the memory up front, even if not known. In testing the cost of them, it was around 50% of the bench time. Using a bump allocator to test doubled the perf when I did it.

olliej 5y ago
Oh they have other things: no white space is a big one. Depending on what they’re allowing they may be able to stop handling character escapes, etc But actual allocation ends up being killer in the JSC parser. I even tried using structure caching to speed up object creation, but it simply did not seem to matter: either there’s too little data to amortize allocations for the necessary data structures, or you’re parsing enough that simple allocations and GC start to happen (and code in c++ can’t optimize the allocations as much as the JIT can)
- beached_whale 5y ago
  I forget what I got when I benchmarked assuming minified, but I already optimized on that anyways. SIMDJson burns through pretty JSON but less so with minified. With C++, there are generally just less allocations, but they probably cost more, not always and I haven't measured malloc/new for small things where they often have a pool setup before going to mmap. They still lock though. But one can often just guess when the number isn't known without much cost on most systems. Choose a size like 1kb and remove the smaller up front allocations, or if the size is known reserve that.
  - olliej 5y ago
    Yeah, I was just looking at their code. It's similarly super heavy on SIMD processing, which would significantly impact the cost of the removed branches - it looks like the masochists supported escape characters. I would be interested in knowing whether they do have any benchmarks to validate the removal of error handling, etc
    - beached_whale 5y ago
      When i am on a pc, I am more curious how they are using simdjson so slowly.

olliej 5y ago

Oh they have other things: no white space is a big one. Depending on what they’re allowing they may be able to stop handling character escapes, etc But actual allocation ends up being killer in the JSC parser. I even tried using structure caching to speed up object creation, but it simply did not seem to matter: either there’s too little data to amortize allocations for the necessary data structures, or you’re parsing enough that simple allocations and GC start to happen (and code in c++ can’t optimize the allocations as much as the JIT can)

beached_whale 5y ago
I forget what I got when I benchmarked assuming minified, but I already optimized on that anyways. SIMDJson burns through pretty JSON but less so with minified. With C++, there are generally just less allocations, but they probably cost more, not always and I haven't measured malloc/new for small things where they often have a pool setup before going to mmap. They still lock though. But one can often just guess when the number isn't known without much cost on most systems. Choose a size like 1kb and remove the smaller up front allocations, or if the size is known reserve that.
- olliej 5y ago
  Yeah, I was just looking at their code. It's similarly super heavy on SIMD processing, which would significantly impact the cost of the removed branches - it looks like the masochists supported escape characters. I would be interested in knowing whether they do have any benchmarks to validate the removal of error handling, etc
  - beached_whale 5y ago
    When i am on a pc, I am more curious how they are using simdjson so slowly.