JSONMBS usage?

Yes, I remembered that, but Kem’s tests are ancient and new benchmarks as of Xojo 2021 would be very helpful.

I’m mostly interested in the speed of JSON lookups through a child or two vs making a dictionary of the child once, then looking up in the child dictionary in my loops. The former makes code cleaner, but I suspect the latter is much faster.

That’s the main reason I haven’t bothered trying it.

Looks like I have in about a dozen projects, all originally dating back years, so at the time I would have used it because of the performance advantages. If I had to refactor to something else, it would not be a big deal to me.

New benchmarks comparing the various JSON and Dictionary alternatives since Xojo 2021 would be enlightening though…

That’s well out of date now, and JSONItem is substantially faster.

So I am about to switch to using a new JSON library which can do more.
The new class should cover > 90% of both old JSONMBS and JSONItem to be a drop in for both.
And it gets a few new features like iterators.

The Convert function will stay of course for @David_Cox.


You may be thinking of The ZAZ: JSON Performance Tests Round 2 which is very out of date these days. I always intended to run another set of tests with Einhugur, but never got around to it. These days, you can’t really go wrong, but I suspect MBS is still the performance king if you need the absolute fastest parsing.

< Instead of derailing this thread, I have created a new one. My apologies, Christian >
Updated JSON Speed Tests Project

1 Like

or not
in fact i use the 3 of the tests, i’m suprised mbs is not way faster than build in

We use it for all JSON processing…
…and they way we are using it is according to the example project we’ve created with you: JSONItem clone

So basically it is the replacement for Xojo’s JSONItem which we are using via your Plugins.

As long as that example project continues to work “as it is” it’s probably fine for us :wink:

For JSONItem_MBS, you would need to remove this in the constructor since the parsing constructor now raises an exception:

If (mJSON.Handle = 0) or (mJSON.ParseError <> "") Then
  Raise New JSONException("JSONMBS ParseError: " + mJSON.ParseError, mJSON.Handle)
End If

and for FromJSON, you need to handle the new types:

Case JSONMBS.kTypeFalse
  Return False
Case JSONMBS.kTypeNumber
  If pJSON.IsInt64 Then Return pJSON.ValueInteger
  Return pJSON.ValueDouble
Case JSONMBS.kTypeString
  Return pJSON.ValueString
Case JSONMBS.kTypeTrue
  Return True

replaced with:

Case JSONMBS.kTypeDouble
  Return pJSON.ValueDouble
Case JSONMBS.kTypeInt64
  Return pJSON.ValueInt64
Case JSONMBS.kTypeUInt64
  Return pJSON.ValueUInt64
Case JSONMBS.kTypeString
  If pJSON.IsInt64 Then Return pJSON.ValueInt64
  If pJSON.IsNumber Then Return pJSON.ValueDouble
  Return pJSON.ValueString
Case JSONMBS.kTypeSingle
  Return pJSON.ValueDouble

or just use JSONMBS as JSONItem replacement itself.

With JSON, something is missing : the currency type.
This is strange because using amounts is very common.
There are 3 ways to use currencies : convert them to double with the risk of having something such as : 125.589999999…
Convert them to string to get “125.59” (with quotes that is quite strange for an amount).
The 3rd way is to build the json as a string and do what we want.

I’ll like to have something like
myJson.value(“amount”) = myCurrencyValue and getting : {…“amount” : 125.59, …}

Or the fourth way, which I’ve seen most often, is to treat the currency as an integer. Multiply by 100 for storage, and divide by 100 for displaying to the user.

1 Like

Our json class stores numbers with string representation.
So a currency can go in and out without trouble.

heu… if this json is in reply of an api, you never know who and what will treat it. (“hey guy, don’t forget to divide this amount by 100 !..”)

Gag : with the same json built with a postgreslql json function :
Xojo jsonitem.tostring gives : “theAmount”:1572078.99,…
Postman gives : “theAmount”:1572078.9899999999907,…

It is, and APIs are where I’ve seen this. All environments will have this problem. JSON is more-or-less typeless. So using an integer is a reliable way to avoid the problem entirely.

That said, it sure would be nice if Xojo were to apply some sort of formatting rules so you would get something like what you see in Postman. But Xojo is aiming for accuracy, and doubles aren’t very accurate. Which… again… is why integers are a common solution.

1 Like

You guys can try JSONMBS class in 23.5pr1 and let me know what you think about it.

I had one error (in three locations). I now have to turn my Variant into a String before I can use it to create a New JSONMBS(String) , but that’s OK.

JSONMBS in 23.5pr1 does not have the “Value” methods, e.g. jsonMbsObject.Value("key") = "value"


  • property Value(index As Integer) as Variant
  • property Value(Key As String) as Variant

ist listed on the website!?
Are you sure the new plugin is loaded?

Yes, the Set-ters for .Value are not (yet) available.

use JSONMBS as JSONItem replacement itself

So one can’t use it as a replacement (by renaming JSONItemJSONMBS).

Additionally: MBS.VersionNumber returns 23.4 (expected: 23.5).
So one can’t use conditional compilation for testing the changes while still using 23.4 for productive usage:

#if MBS.VersionNumber < 23.5 then
  'existing productive (shared) code
  'modified to work with MBS 23.5

I know of the version number problem. Fixed for pr2, but confused a few users.

The Value setter works for me already:

Dim j As New JSONMBS
j.Value("test") = 1234