Synopse Open Source

We have just added a new "25 - JSON performance" sample to benchmark JSON process, using well most known Delphi libraries...

A new fight
featuring
mORMot vs SuperObject/XSuperObject/dwsJSON/DBXJSON

On mORMot side, it covers TDocVariant, late binding, TSQLTable, ORM, record access, BSON...

We tried to face several scenarios:

• parse/access/write iteration over a small JSON document,
• read of deeply nested 680 KB JSON (here mORMot is slower than SO/dwsJSON),
• read of one 180 MB JSON file (with on-the-fly adaptation to fit a record layout),
• named access to all rows and columns of a 1 MB JSON table, extracted from a SQL request (with comparison with our ORM performance).

On average and in details, mORMot is the fastest in almost all scenarios (with an amazing performance for table/ORM processing), dwsJSON performs very well (better than SuperObject), and DBXJSON is the slowest (by far, but XE6 version is faster than XE4).

As we already stated, we finished the first step of integration of the SpiderMonkey engine to our mORMot framework.
Version 1.8.5 of the library is already integrated, and latest official revision will be soon merged, thanks to mpv's great contribution.
It can be seen as stable, since it is already used on production site to serve more than 1,000,000 requests per day.

You can now easily uses JavaScript on both client and server side.
On server side, mORMot's implementation offers an unique concept, i.e. true multi-threading, which is IMHO a huge enhancement when compared to the regular node.js mono-threaded implementation, and its callback hell.
In fact, node.js official marketing states its non-blocking scheme is a plus. It allows to define a HTTP server in a few lines, but huge server applications need JavaScript experts not to sink into a state a disgrace.

With revision 1.18 of the framework, we just introduced two new custom types of variants:

• TDocVariant kind of variant;
• TBSONVariant kind of variant.

The second custom type (which handles MongoDB-specific extensions - like ObjectID or other specific types like dates or binary) will be presented later, when dealing with MongoDB support in mORMot, together with the BSON kind of content. BSON / MongoDB support is implemented in the SynMongoDB.pas unit.

We will now focus on TDocVariant itself, which is a generic container of JSON-like objects or arrays.
This custom variant type is implemented in SynCommons.pas unit, so is ready to be used everywhere in your code, even without any link to the mORMot ORM kernel, or MongoDB.

TDocVariant documents

TDocVariant implements a custom variant type which can be used to store any JSON/BSON document-based content, i.e. either:

• Name/value pairs, for object-oriented documents;
• An array of values (including nested documents), for array-oriented documents;
• Any combination of the two, by nesting TDocVariant instances.

Here are the main features of this custom variant type:

• DOM approach of any object or array documents;
• Perfect storage for dynamic value-objects content, with a schema-less approach (as you may be used to in scripting languages like Python or JavaScript);
• Allow nested documents, with no depth limitation but the available memory;
• Assignment can be either per-value (default, safest but slower when containing a lot of nested data), or per-reference (immediate reference-counted assignment);
• Very fast JSON serialization / un-serialization with support of MongoDB-like extended syntax;
• Access to properties in code, via late-binding (including almost no speed penalty due to our VCL hack as already detailed);
• Direct access to the internal variant names and values arrays from code, by trans-typing into a TDocVariantData record;
• Instance life-time is managed by the compiler (like any other variant type), without the need to use interfaces or explicit try..finally blocks;
• Optimized to use as little memory and CPU resource as possible (in contrast to most other libraries, it does not allocate one class instance per node, but rely on pre-allocated arrays);
• Opened to extension of any content storage - for instance, it will perfectly integrate with BSON serialization and custom MongoDB types (ObjectID, RegEx...), to be used in conjunction with MongoDB servers;
• Perfectly integrated with our Dynamic array wrapper and its JSON serialization as with the record serialization;
• Designed to work with our mORMot ORM: any TSQLRecord instance containing such variant custom types as published properties will be recognized by the ORM core, and work as expected with any database back-end (storing the content as JSON in a TEXT column);
• Designed to work with our mORMot SOA: any interface-based service is able to consume or publish such kind of content, as variant kind of parameters;
• Fully integrated with the Delphi IDE: any variant instance will be displayed as JSON in the IDE debugger, making it very convenient to work with.

To create instances of such variant, you can use some easy-to-remember functions:

• _Obj() _ObjFast() global functions to create a variant object document;
• _Arr() _ArrFast() global functions to create a variant array document;
• _Json() _JsonFast() _JsonFmt() _JsonFastFmt() global functions to create any variant object or array document from JSON, supplied either with standard or MongoDB-extended syntax.

For both our SynOleDB and SynBigTable units, we allow late-binding of data row values, using a variant and direct named access of properties. Thanks to this unique feature (as far as I know in the Delphi database world),

This allows clear and valid code as such:

var Customer: Variant;
begin
  with Props.Execute(
    'select * from Sales.Customer where AccountNumber like ?',
    ['AW000001%'],@Customer) do
    while Step do
      assert(Copy(Customer.AccountNumber,1,8)='AW000001');
end;

In practice, this code is slower than using a standard property based access, like this:

    while Step do
      assert(Copy(Column['AccountNumber'],1,8)='AW000001');

But the first version, using late-binding of column name, just sounds more natural.

Of course, since it's late-binding, we are not able to let the compiler check at compile time for the column name. If the column name in the source code is wrong, an error will be triggered at runtime only. But it would not be an issue, since it would be the same for the SQL code inserted: it's only executed at runtime (this is one of the benefits of using an ORM, by the way: the ORM will generate correct SQL code for you...).

The default VCL implementation of this late-binding was a bit slow for our purpose.
Since it has to deal with Ole Automation, and because it's fun, we hacked the VCL to provide a lighter and faster version for our custom variant types.