-
|
In my use case it's difficult to pad the json without allocating a new buffer and copying to it, but my application is performance-critical so the allocation overhead is significant. So the questions are:
|
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 7 replies
-
|
Do you control the initial allocation of the buffer you read your JSON into, and can you pad that initial allocation a bit to match? There isn't currently a great workaround -- you can use the fallback parser but it doesn't use simd and is slower. There are a couple of reasons we need padding, but one important reason is that we can do faster string processing by reading 8-64 bytes at a time, including when we are at the end of the string (we just retroactively cap the string when we find the end quote). |
Beta Was this translation helpful? Give feedback.
-
That's the problem - I don't.
Is it one of the other open-source libraries such as yyjson? |
Beta Was this translation helpful? Give feedback.
-
|
No, it was written as part of simdjson. We have multiple backends / kernels for different architectures--arm, Intel with 128-, 256- and 512-bit SIMD, powerpc, and generic 64-bit fallback that runs on anything. Generally we pick the fastest one for your machine, but you can override it. Your application code using simdjson doesn't change, you just switch out kernels. |
Beta Was this translation helpful? Give feedback.
-
It is safe as long as the end of the string is at least |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for elaborating!
I didn't do any special handling for page boundary so I guess it's just luck :p |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, segfault from accessing that SIMDJSON_PADDING bytes is the only potentially bad outcome I know of. You can even store other stuff in the padding bytes if you want. simdjson does not write to the padding or care about its contents, but it does read the bytes from memory as part of its main loop. (This allows us to read the document N bytes at a time all the way to the end.) |
Beta Was this translation helpful? Give feedback.
-
|
Thank you both for the explanation! I have another question that could use your help: I can mitigate my problem by switching to a faster allocator for the padded string (but other allocations in the parser are still std So the code without those auto doc = parser.iterate(m_compressedPadded, m_compressedLength, m_compressedLength);The code with auto doc = parser.iterate(m_compressedPadded, m_compressedLength, m_compressedLength + SIMDJSON_PADDING);What am I doing wrong here? |
Beta Was this translation helpful? Give feedback.
-
|
A simdjson parser only allocates if the document being encountered is bigger than any it's encountered before. Basically it grows its buffers but never shrinks them, so that you reach a steady state. If you're doing the second line before the first one, that's what will happen. If you're not sure, you can check this by telling simdjson not to allocate by preallocating and preventing growth: parser.allocate(m_compressedLength); // Preallocate to max capacity
parser.set_max_capacity(m_compressedLength); // Prevent growthAfter that, do your parser.iterate() calls and they will either run without allocating, or return an error (if the document is bigger than max capacity). That should at least tell you that document size increase is indeed what's happening. |
Beta Was this translation helpful? Give feedback.
-
|
Please see... I provide a complete example. |
Beta Was this translation helpful? Give feedback.
-
|
That's a neat trick! |
Beta Was this translation helpful? Give feedback.
-
|
@Gun9niR I wish we could use it generally but there is much resistance to it. Yet, as a user of the library, you can definitively do it. |
Beta Was this translation helpful? Give feedback.
Do you control the initial allocation of the buffer you read your JSON into, and can you pad that initial allocation a bit to match?
There isn't currently a great workaround -- you can use the fallback parser but it doesn't use simd and is slower. There are a couple of reasons we need padding, but one important reason is that we can do faster string processing by reading 8-64 bytes at a time, including when we are at the end of the string (we just retroactively cap the string when we find the end quote).