Comparing the speed of JSONItem, JSONItem_MTC, and Xojo.Data...

TL;DR: They all leave you wanting more. Xojo.Data is massively faster, but you’re stuck with new framework data types and a very expensive manual operation if you need pretty printing. JSONItem and JSONItem_MTC trade blows with JSONItem_MTC being significantly faster for generation, but not always faster for parsing.

This is an area of Xojo that could use some attention.

You tested 64-bit compiled? Never mind, I see you did.

That’s available in my project too, but I think the speeds are more inline with JSONItem_MTC.

None of these tests were with compiled code, all in the debugger. And unfortunately, the first draft had to be adjusted because I forgot that Windows still defaults to 32-bit, and times were actually better that way. But I had to use the 64-bit Times to be fair.

Yes, I tried that after the first draft and it performed slightly better than JSONItem_MTC, it wasn’t different enough to warrant including.

Oh. If you post your test code, I’d be happy to post the results of the compiled version.

not to mess with your tests but have you looked at Einhugur & MonkekBread’s plugins. each has a JSON class for parsing json. Supposedly they are both much faster that the built in ones. I have not bench marked them myself.


He mentioned in his blog that he didn’t want to go with a plugin since it’s for an open-source project.

Thom, if you test compile with 64-bit Aggressive, you should find that JSONItem_MTC is significantly faster than what you posted in your blog. Parsing in my tests runs at about 0.5X the speed of the new framework. To be clear, the new framework stuff is still the fastest, but my code is significantly faster than JSONItem and much closer to the new framework.

Still I would appreciate if you compare with our classes, too.
Just to know for me where I stand with them.

10 MB JSON? Is this really a good idea? And a test project would really help.

Yes. There are lots of objects to serialize. I don’t expect I could write a custom markup that I could parse faster, is version control friendly, and human readable. Plus, I can (and do) parse the documents in my PHP-based API, as well as having some PostgreSQL triggers able to act on the document data with relatively little code.

[quote=429746:@Christian Schmitz]Still I would appreciate if you compare with our classes, too.
Just to know for me where I stand with them.[/quote]
Yeah, as mentioned I was originally testing for my own project, but this experiment has grown a little bit, so I’ll include MBS in round 2.

I will run the next round in compiled mode, but my original logic is that any performance gained in JSONItem_MTC would also be gained by JSONItem since they’re both Xojo-based. So the overall outcome wouldn’t change. But yes, compiling will get us closer to an apples-to-apples comparison so I’ll do that.

I missed that in the article. oops. my bad.[quote=429746:@Christian Schmitz]Still I would appreciate if you compare with our classes, too.
Just to know for me where I stand with them.[/quote]

I am curious too. As I use the “classic” framework and the new new new framework. Not any of the xojo.. framework.

Well you didn’t have to wait long!

The summary is as Kem expected. Performance is way better for JSONItem_MTC, but still can’t keep pace with the plugin-based solutions of Xojo.Data and MBS. Speaking of MBS, it absolutely annihilates the competition in every one of these tests.

Great. Classes made for speed.

By the way, we have a class to wrap JSONMBS for making it compatible to JSONItem.

see example project: JSONItem clone

Hey that’s not bad.

Fair test, Thom. Thanks for reporting those results.

faster/sooner than I expected. thanks!!

Well, one more followup than I expected to be doing:

I thought I remembered that from when I tested MBS, but that was a while ago and thought things had changed.