Leaderboard

I've created an example for you. XY-GraphSelection.vi

That's nothing to sniff at. At some point you just have to say "this is the wrong way to approach this problem". JSON isn't a high performance noSQL database - it's just a text format and one designed for a non-threaded, interpreted scripting language (so performance was never on the agenda . )

Only 125MB/sec, but I was testing calling 'SELECT json_extract($json,$path)' which has the extra overhead of getting the JSON string in and out of the db. I wish I could match 300MB/sec in LabVIEW.

I’d add: - Work on a stream (i.e. allow the JSON Value to be followed by something else, like the regular Flatten functions have a “Rest of String” output). - Give useful error messages that include where in the very long JSON text the parser had an issue. - Work with “sub”JSON. Meaning, “I know there is an “Options” item, but it can come in multiple forms, so just return me that item as JSON so I can do more work on it (or pass it on to an application subcomponent that does know what the form is). The library I’m working on, JSONtext, is trying to be sort of an extension to the inbuilt JSON primitives that adds all these features.