You probably know about our SynLZ compression unit, in pascal and x86 asm, which is very fast for compression with a good compression ratio, and proudly compete with LZ4 or Snappy. It is used in our framework everywhere, e.g. for WebSockets communication, for ECC encrypted file content, or to […]
For mORMot, we developed a fully feature direct access layer to any RDBMS, implemented in the SynDB.pas unit.
You can use those
SynDB classes to execute any SQL statement,
without any link to the framework ORM.
At reading, the resulting performance is much higher than using the standard
TDataSet component, which is in fact a true performance
It has genuine features, like column access via late-binding, an innovative
ISQLDBRows interface, and ability to directly access
the low-level binary buffers of the database clients.
We just added a nice feature to those classes: the ability to access
remotely, via plain HTTP, to any
SynDB supported database!
We have just committed some enhancements to interface-based service process.
TSQLRestRoutingREST will now recognize several URI schemes,
root/Calculator/Add?n1=1&n2=2 alternative could
be pretty convenient to be consumed from some REST clients.
Please find here a documentation update.
Little mORMots have a very efficient transmission protocol, in their mountains...
Most mORMots are highly social and use loud whistles to communicate with one another, especially when alarmed.
As stated by Wikipedia
In a comment of the already quoted blog article about DataSnap performance issues, Tom asked this interesting question about mORMot, after I presented how we like to use http.sys kernel-mode server to achieve best performance possible over HTTP:
What about TCP communication, http is not the only Internet protocol. Protobuf, Thrift, MsgPack, BSON etc, is binary protocol and http i big overhead in some systems.
Did http.sys enable use of tcp/ip socket protocol?
As stated during our
recent benchmarks, the default SQlite3 write speed is quite slow,
when running on a normal hard drive. By default, the engine will pause after
issuing a OS-level write command. This guarantees that the data is written to
the disk, and features the
ACID properties of the database
ACID is an acronym for "Atomicity Consistency Isolation
Durability" properties, which guarantee that database transactions are
processed reliably: for instance, in case of a power loss or hardware failure,
the data will be saved on disk in a consistent way, with no potential loss of
You can overwrite this default behavior by setting the
TSQLDataBase.Synchronous property to
smOff instead of
smFull setting. When
Synchronous is set
smOff, SQLite continues without syncing as soon as it
has handed data off to the operating system. If the application running
SQLite crashes, the data will be safe, but the database might become
corrupted if the operating system crashes or the computer loses power before
that data has been written to the disk surface. On the other hand, some
operations are as much as 50 or more times faster with this setting.
When the same tests are performed with
smOff, "Write one" speed is enhanced from 8-9 rows per second into about
400 rows per second, on a physical hard drive (SSD or NAS drives may not suffer
from this delay). We'll show below the detailed benchmark results.
So depending on your application requirements, you may switch Synchronous setting to off, to enhance server-side responsiveness.
Our ORM RESTful Framework is about to access any available database engine.
It will probably change its name (since it won't use only SQlite3 as database), to become mORMot - could be an acronym for "Manage Object Relational Mapping Over Tables", or whatever you may think of...
We'll still rely on SQLite3 on the server, but a dedicated mechanism will allow to access via OleDB any remote database, and mix those tables content with the native ORM tables of the framework. A flexible Virtual Tables and column mapping will allow any possible architecture: either a new project in pure ORM, either a project relying on an existing database with its own table layout.
2011-06-16. Pascal Programming
After a question on StackOverflow, I wanted to comment about the speed of generated code by diverse Delphi compiler versions.
Since performance matters when we write general purpose libraries like ours, we have some feedback to propose:
The SQlite3 engine has ability to create Virtual Tables from code. From the perspective of an SQL statement, the virtual table object looks like any other table or view. But behind the scenes, queries from and updates to a virtual table invoke callback methods on the virtual table object instead of reading and writing to the database file.
The virtual table mechanism allows an application to publish interfaces that
are accessible from SQL statements as if they were tables. SQL statements can
in general do anything to a virtual table that they can do to a real table,
with the following exceptions:
- One cannot create a trigger on a virtual table.
- One cannot create additional indices on a virtual table. (Virtual tables can have indices but that must be built into the virtual table implementation. Indices cannot be added separately using
- One cannot run
ALTER TABLE ... ADD COLUMN commands against a
- Particular virtual table implementations might impose additional constraints. For example, some virtual implementations might provide read-only tables. Or some virtual table implementations might allow
DELETE but not
UPDATE. Or some virtual table
implementations might limit the kinds of
UPDATEs that can be
Example of virtual tables, already included in the SQLite3 engine,
are FTS or
RTREE tables. A
custom virtual table might represent in-memory data structures (like
TSQLVirtualTableJSON, TSQLVirtualTableBinary). Or it might
represent a view of data on disk that is not in the SQLite3 format
TSQLVirtualTableLog). Or the application might compute the
content of the virtual table on demand.
Thanks to the generic implementation of Virtual Table in SQLite3,
you can use such tables in your SQL statement, and even safely execute a
SELECT statement with
JOIN or custom functions,
mixing normal SQLite3 tables and any other Virtual Table.
A dedicated mechanism has been added to the framework, beginning with revision 1.13, in order to easily add such virtual tables with pure Delphi code, just by inheriting some classes.
2010-07-11. Open Source
Didn't you ever wanted to unzip some archive content, or embed a zip file into your exe?
Didn't you ever wanted to create a zip archive file, from some data in memory, in pure Delphi code, without using any external dll?
One of the open source unit we use allow you to do these tasks in a easy way.
In our Source Code repository you would have perhaps noted the SynLZ.pas and SynLZO.pas units.
These are two in-memory compression units, optimized for speed.
SynLZ is a brand new LempelZiv-based compression algorithm, the fastest around for compression speed, so very suitable for using on Server side, with very low CPU consumption.