Forum > General
A new design for a JSON Parser
sysrpl:
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 created a new design for a JSON parser that is pretty small, yet powerful.
If you're interested, I've posted the code under GPLv3 and a write up of my thought process and the workflow of using a single small class to work with JSON:
https://www.getlazarus.org/json/
Any and all feedback is welcome.
Update: Aug 1 2021
I've posted an update that fixes an issue with escaped double quote characters and adds some convenience methods. You may read more about the update at the page linked above.
k1ng:
Hey,
nice work! Would be nice to see a speed comparison with LkJSON :)
sysrpl:
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.
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?
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.
marcov:
(the pooling functionality in the fcl-XML unit has also been designed out over time, to sensitive, maintenance wise)
k1ng:
--- Quote from: sysrpl on August 26, 2019, 11:51:17 am ---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.
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.
--- End quote ---
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.
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---js := TlkJSONObject.Create();js := TlkJSON.ParseText(jsonstr) as TlkJSONObject; if js.Field['name'].Field['surname'].SelfType <> jsNull then surname := String(js.Field['name'].Field['surname'].Value);
So for me it seems both are working more or less the same just with a different in usage when getting values. For the latter I'd prefer your version as one don't need some typecast. Using AsString etc is more common in recent Delphi/FPC.
It was just a suggestion because I think more users would use your library if it's also faster/comparable to LkJSON, just with a better syntax. So it'd be another pro to try your version ;)
--- Quote from: sysrpl on August 26, 2019, 11:51:17 am ---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?
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.
--- End quote ---
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...
Navigation
[0] Message Index
[#] Next page