Arnaud Bouchez

For the TLS layer, I did not notice any huge performance problem during the transmission. Only the certificate checking may take longer than before.

IIRC the keep alive time out is not about idle time, but total existing time of the whole connection.

You may have noticed that the OpenSSL 1.1.1 series will reach End of Life (EOL) next Monday... Most sensible options are to switch to 3.0 or 3.1 as soon as possible. But we also discovered that switching to OpenSSL 3.0 could led into big performance regressions... so which version do we need to use? 😮 I just published a blog article about this, and also how we tried to leverage any incompatibility issue within the mORMot OpenSSL layer: https://blog.synopse.info/?post/2023/09/08/End-Of-Live-OpenSSL-1.1-vs-Slow-OpenSSL-3.0

Where to start? 1) Use TArray<integer> instead of array of integer (seems incredible - see below) 2) ARC -- happily removed since 10.4 Sidney 3) Language level incompatibilities: RawByteString, shortstring... 4) The LongInt and LongWord Data Type are different on 64-bit POSIX platforms (WTF) 5) too-much-moving target (it is almost impossible to target several Delphi compiler versions at once for mobile targets) 6) lack of ASM inlined blocks (and we have a lot of very good asm in mORMot) 7) LLVM backend issues (floating point performance, inlining inconsistency with Delphi compiler) ... in short: when you compare with FPC e.g. on Linux x64, most latest Delphi design decisions just make no sense About point 1) I am not sure but I got it from official Delphi documentation: https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Migrating_Delphi_Code_to_Mobile_from_Desktop This is just a b**s**t idea because at the compiler level "array of" and "TArray<>" are handled the same internally IIRC. It just breaks code with pre-generics compilers we prefer to support. So from now on, it was not possible to envisage Delphi "mobile" compiler compatibility without a lot of work. We do not want to pollute our source code with IFDEF everywhere, just to circumvent Delphi inconsistencies.

Good question. 😉 The multi-platform of mORMot 2 was deeply enhanced, but mostly about how it is implemented. Most system-specific code is now within mormot.core.os.pas. It now eases a lot the port to other systems. But currently, about Delphi platform supports, we only support Win32/Win64. Other platforms are supported on FPC only. Some new platforms are supported in mORMot 2 like Linux arm32 and aarch64, or Darwin/MacOS aarch64. We test them with our CI farm (using Mac M1 VM, or even a RPi). The reasons are: 1) we don't need it for our own projects 2) we don't own any Delphi licence with Mobile and Linux support 3) FPC cross-platform support is just much better than Delphi (exact same compiler and features everywhere) and don't break anything between versions 4) we certainly would need a lot of IFDEF to support those platforms - which we are very reluctant to do 5) for a FMX app, it is likely to need only some REST client support, which does not require the whole mORMot feature set - and you can generate client code for FMX To be more precise, with mORMot 2, we still need to fix the client code generation (which is not fully debugged), and introduce some cross-platform client units, which are likely to support TMS WebCore instead of SmartMobileStudio.

We are pleased to announce the release of mORMot 2.1. The download link is available on https://github.com/synopse/mORMot2/releases/tag/2.1.stable The reference blog article was just published at https://blog.synopse.info/?post/2023/08/24/mORMot-2.1-Released Here is an extract of the release notes: Added (C)LDAP, DNS, (S)NTP clients Command Line Parser Native digest/basic HTTP servers authentication Angelize services/daemons manager TTunnelLocal TCP port forwarding SHA-1/SHA-256 HW opcodes asm 7Zip dll wrapper OpenSSL CSR support PostgreSQL async DB with HTTP async backend (for TFB) LUTI continous integration cross-platform farm Changed Upgraded SQLite3 to 3.42.0 Stabilized Mac x86_64/aarch64 platforms Lots of bug fixes and enhancements Any feedback is welcome! 🙂

Generation of SQL with parameters should help the performance and security.

Nice seeing another growing project using mORMot. 😉 You can post the offer on Synopse forum, too, if you want.

From the asm shown in the video, it seems to compare WORD PTR characters, so it is likely to be UTF-16.

1) TL&WR Do not try to use those tricks in anything close to a common-use hash table, e.g. your own data library. So much micro-benchmarking for no benefit in practice: all this is not applicable to a common-use library. The Rust RTL has already been optimized and scrutinized by a lot of people and production workloads. I would never try to apply what he found for his own particular case to any hash table implementation. 2) hash function From profiling on real workloads, with a good enough hash function, there are only a few collisions. Of course, FNV is a slow function, with a bad collision rate. With a good hash function, e.g. our AesNiHash32 from https://github.com/synopse/mORMot2/blob/master/src/crypt/mormot.crypt.core.asmx64.inc#L6500 which is inspired by the one in Go RTL, comparing the first char is enough to reject most collisions, due to its almost-random hash spreading. Then, the idea of "tweaking the hash function" is just a pure waste of computer resource for a common-use library, once you have a realistic hash table with thousands (millions) of items. Of course, this guy want to hash a table of a few elements, which are known in advance. So it is not a problem for him. So no hash function was the fastest. Of course. But this is not a hash table any more - it is a dedicated algorithm for a specific use-case. 3) security Only using the first and last characters is an awful assumption for a hash process in a common library. It may work for his own dataset, but it is a very unsafe practice. This is the 101 of hash table security: don't make it guessable, or you would expose yourself to hash flooding http://ocert.org/advisories/ocert-2012-001.html 4) one known algorithm for such a fixed keyword lookup The purpose of this video is to quickly find a value within a fixed list of keywords. And from what I have seen in practice, some algorithms would perform better because won't involve a huge hash table, and won't pollute the CPU cache. For instance, this code is used on billions of computers, on billions of datasets, and works very well in practice: https://sqlite.org/src/file?name=src/tokenize.c&amp;ci=trunk The code is generated by https://sqlite.org/src/file?name=tool/mkkeywordhash.c&amp;ci=trunk An extract is: /* Check to see if z[0..n-1] is a keyword. If it is, write the ** parser symbol code for that keyword into *pType. Always ** return the integer n (the length of the token). */ static int keywordCode(const char *z, int n, int *pType){ int i, j; const char *zKW; if( n>=2 ){ i = ((charMap(z[0])*4) ^ (charMap(z[n-1])*3) ^ n*1) % 127; for(i=((int)aKWHash[i])-1; i>=0; i=((int)aKWNext[i])-1){ if( aKWLen[i]!=n ) continue; zKW = &zKWText[aKWOffset[i]]; if( (z[0]&~0x20)!=zKW[0] ) continue; if( (z[1]&~0x20)!=zKW[1] ) continue; j = 2; while( j<n && (z[j]&~0x20)==zKW[j] ){ j++; } if( j<n ) continue; *pType = aKWCode[i]; break; } } return n; } Its purpose was to reduce the code size, but in practice, it also reduces CPU cache pollution and tends to be very fast, thanks to a 128 bytes hash table. This code is close to what the video proposes - just even more optimized.

---

Don't mess with the threads or DB connections of the HTTP/REST server. You would depend on an implementation detail of Mars, with no guaranty it stays the same in the future. If you have a long process, then a temporary dedicated connection is just fine. You could reuse the thread and its connection, for the next requests: add a queue to your thread, for pending requests.

We just introduced in our Open Source mORMot 2 framework two client units to access DNS and LDAP/CLDAP servers. You can resolve IP addresses and services using DNS, and ask for information about your IT infrastructure using LDAP. There are not so many working and cross-platform OpenSource DNS and LDAP libraries around in Delphi or FPC, especially compatible with the latest MS AD versions. And none was able to use Kerberos authentication, or signing/sealing, AFAIK. Last but not least, its DNS and CLDAP server-auto-discovery feature is pretty unique. Please see https://blog.synopse.info/?post/2023/04/19/New-DNS-and-(C)LDAP-Clients-for-Delphi-and-FPC-in-mORMot-2 🙂

Both syntax are of course supported. This is explained in the blog article: What is your exact concern? Is it that you want the quotes to be supported too? Such quotes are not cross-platform I guess. The parser don't read quotes, because they are in fact parsed at OS level. IMHO the correct way is to write either /path "C:\Program Files\mORMotHyperServer\" or "/path=C:\Program Files\mORMotHyperServer\" But I did not test this. Any feedback is welcome.

For most projects, we want to be able to pass some custom values when starting it. We have ParamStr and ParamCount global functions, enough to retrieve the basic information. But not enough when you want to go any further. We just committed a new command line parser to our Open Source mORMot 2 framework, which works on both Delphi and FPC, follows both Windows not POSIX/Linux conventions, and has much more features (like automated generation of the help message), in an innovative and easy workflow. The most simple code may be the following (extracted from the documentation): var verbose: boolean; threads: integer; ... with Executable.Command do begin ExeDescription := 'An executable to test mORMot Execute.Command'; verbose := Option(['v', 'verbose'], 'generate verbose output'); Get(['t', 'threads'], threads, '#number of threads to run', 5); ConsoleWrite(FullDescription); end; This code will fill verbose and threads local variables from the command line (with some optional default value), and output on Linux: An executable to test mORMot Execute.Command Usage: mormot2tests [options] [params] Options: -v, --verbose generate verbose output Params: -t, --threads <number> (default 5) number of threads to run So, not only you can parse the command line and retrieve values, but you can also add some description text, and let generate an accurate help message when needed. More information available at https://blog.synopse.info/?post/2023/04/19/New-Command-Line-Parser-in-mORMot-2