Speeding up DOM parsing?

[DUOLabs333]

Using the DOM api, simdjson takes up 20% of runtime (I got this statistic from the perf profiler) from stage1 and stage2. Here's the line I use for parsing: auto json=map_from(curr->parser.parse(line).get_object());. map_from extracts the key-value pairs and puts them in an unordered_map, and line is a string_view.

[lemire]

I don't think that you are providing enough details. However, if, as you say, simdjson takes up only 20% of the running time of your application, then your main bottleneck is elsewhere, and that's elsewhere you must look. That is, if simdjson accounts for 20% of the running time, even if we made simdjson infinitely faster, you'd only gain 20% in speed.

[lemire]

It is important to understand the point I made: Even if simdjson was made infinitely fast, your application would only save 20%. Of course, we can't make simdson infinitely fast, so you can't ever hope for 20%.

I couldn't use ondemand because of the lack of is_string

You can check that an element is of type string in On Demand with e.type() == json_type::string. We could add the convenience method is_string() if that's the only concern.

[lemire]

To spin my answer differently, by how much are you hoping to accelerate your code? E.g., do you hope to double its speed?

[DUOLabs333]

I'm not sure exactly how much further I could optimize my code without hurting readability, but I'm aiming so that the network is the main bottleneck.

[jkeiser]

I do think "entire JSON parser takes 20%" and "hash function takes 15%" is not comparing apples and oranges :) At the bare minimum, a parser necessarily has to scan every single character in the file, while the hash function only needs to scan the characters in the keys. In practice you likely need the parser to do a lot of other work to do beyond just scanning--deserializing numbers, interpreting escape codes in strings, validation, and and keeping track of JSON structure at an absolute minimum. None of that can be eliminated without a cost in functionality, and all of it comes at a runtime cost.

Not that simdjson can't be sped up--I'm sure there are savings to be had--but it has been extensively tuned explicitly for performance over many years and is literally the fastest software JSON parser in existence.

There is a cost to the DOM API, however, and you will get at least some speed increase from on demand, as it gets rid of one entire loop over the file and avoids creating an entire intermediate representation of the file.

Further performance can be wrung from simdjson if you know your use case. For example, there are ways to make your application faster if you know some things about the actual structure of this map, or about the usage:

• If the parser is not reused while the map is alive, you can store string_views instead of strings, avoiding extra allocations.
• If you expect a limited, known set of key names, you can read into a structure instead of a map.
• If individual fields will never be accessed more than once, or if applications may not access some values at all, you may be able to delay the actual parsing of the values until they are used. This is probably a more complex fix, but particularly if values can't be arrays or objects, might be doable.

[DUOLabs333]

You can check that an element is of type string in On Demand with e.type() == json_type::string

That's perfect! That was the only thing stopping me from trying it out.

Yeah, I think I'm hitting the limits on JSON parsing, and will have to look elsewhere for a speed-up.

[DUOLabs333]

Yeah, I tried yyjson, and am still getting 20% of runtime --- I think that's the limit on how fast my json can be parsed.

[DUOLabs333]

I tried using the ondemand API, but keep getting OUT_OF_ORDER_ITERATION. I'm still saving the values into a map (at least for now) --- does this mean I can't iterate through a map to save the values for future consumption?

[lemire]

@DUOLabs333 With On Demand, you go through the values once. So if you encounter an array, then you go through the array (moving forward), and consume the values as you find them. Same with an object. The most likely reason for getting OUT_OF_ORDER_ITERATION is that you are accessing the data in a random order. Please see our examples.