I am unsure how fast or slow it is, but I didn't design it for speed. That's not to say it's slow, but it's meant to be small, with powerful features, and just one class / unit.I'm not sure how LkJSON works internally but I assume it also creates objects for each node as you refer to them via Field identifier.
With regard to speed, I am creating 1 pascal object for every node. If I wanted to make it fast I would getmem for many objects at once, and neither create nor destroy them. Instead I would put or get object memory from that pool and not heap allocation / deallocation an object for each node parsed.
That said, would it really be worth it? Do your programs spend most of their time parsing JSON? Are you writing a heavy traffic outward facing service that parses JSON frequently?No, personally I don't need much JSON parsing but others may do. E.g. if your library is 100x times slower than LkJSON (I don't know if there are any other Delphi+FPC JSON Parsers) many people wouldn't use your version as the only 'pro' would be the different syntax but as you only need to write code once...
If this is the case and speed / scalability is a concern then you probably want to switch to nodejs which is optimized for heavy traffic and parallelization, and is based on JSON to boot. Many smart engineers have designed nodejs for exactly this use case.
I don't know if there are any other Delphi+FPC JSON Parsers
https://www.getlazarus.org/json/I could not connect https because of invalid certificate. I could not connect http because OpenDNS flagged site as malware.
I think I missed the difference between the two. From your example, you go for the second after setting N to stuff node and in this case, stuff node is the root? Then what is current node here? If instead you go for the first, what will you get?
... AnyNode.Find('search/for/name'); // returns a node 3 levels from the current node AnyNode.Find('/search/for/name'); // returns a node 3 levels from the root node
It the same as if you were typing a file system path. If your path string brings with a forward slash, then the path identities an item starting at the root of the files system. If it does not start with a forward slash, then the path evaluates from the current directory.If that's so, recalling your example:
I know the FCL already has a capable JSON parser, but I am writing some Amazon web service interfacing projects and wanted a smaller easier to use JSON parser to assist. I've create a new design for a JSON parser that is pretty small, yet powerful.
Is it just me or is your page getlazarus always redirecting to youtube?
Maybe the site has been hacked?
getlazarus has never been an official source.
Any and all feedback is welcome.
I know the FCL already has a capable JSON parser, but I am writing some Amazon web service interfacing projects and wanted a smaller easier to use JSON parser to assist. I've create a new design for a JSON parser that is pretty small, yet powerful.
If your interested, I've posted the code under GPLv3 and a write up of my thought process and the workflow of using an single small class to work with JSON:
https://www.getlazarus.org/json/
Any and all feedback is welcome.
In poking into the fpjson code I see it uses FloatToStr and TryStrToFloat which internationalize, assuming DefaultFormatSettings is initialized.
"SubData":{...}And what I want is:
{...}
In poking into the fpjson code I see it uses FloatToStr and TryStrToFloat which internationalize, assuming DefaultFormatSettings is initialized.
Floating point numbers are really broken
Never use FloatToStr. Besides the format settings, it is printing 15 digit numbers, which is not enough to encode a double precisely. Use Str directly
Do you know of bug reports, or third party tools?
Do you know of bug reports, or third party tools?
For JSONTools, if that is what you are referring to, I believe you can report bugs here: JSONTools Github Issues (https://github.com/sysrpl/JsonTools/issues).
Do you know of bug reports, or third party tools?
Do you know of bug reports, or third party tools?
here: https://bugs.freepascal.org/view.php?id=29531