Arnaud Bouchez

Perhaps fun for you, but certainly complicated and slower than a simple "while" loop, especially when the process within the loop is small and the range is huge. The duplicated SetLength() is just so "funny".

Just use a while loop! This is the clear and efficient way of writing such code, without messing with the "for" variable. var i: integer; begin i := 1; while i <= 10 do begin Writeln(i); inc(i, 2); end; Readln; end. Or a repeat .. until of course: var i: integer; begin i := 1; repeat Writeln(i); inc(i, 2); until i > 10; Readln; end.

I think the compiler is lost since you didn't put any parameter to your external function definition. It is just the same for the result parameter in RAX as for regular parameters. Try with the exact function definition including all parameters, and I hope (crossed fingers!) it will be fine. The "stack frames" parameter in the Project Options is pointless on Win64 IIRC. Only with an `asm .noframe` directive you may have no stack frame. IMHO the redirection call won't be noticeable in performance, especially if you write: asm .noframe jmp AVXGENERATE_TSLIVERHELPER_NS end; I wouldn't play with inline + assembly with Delphi, which has a long history of problems when inlining code...

The SQLite3 documentation you quoted didn't take into account that a client/server layer like mORMot. And for this use case (mORMot + SQlite3), it states the contrary in https://www.sqlite.org/whentouse.html

@Hans J. Ellingsgaard You are making assumption, I am afraid. On the server side, a single SQlite3 insert takes a few microseconds. A batched SQlite3 from our ORM (i.e. several inserts per requests) writes at 200,000 inserts per second on a laptop. See https://synopse.info/files/html/Synopse mORMot Framework SAD 1.18.html#TITL_59 No remote client/server DB I know is so fast, even running on localhost. And from concurrent writers over HTTP, you got more than 6000 inserts per second on a laptop with 200 concurrent clients (one insert per request). See https://synopse.info/files/html/Synopse mORMot Framework SAD 1.18.html#TITL_4 This is faster than regular client/server databases, and we tested it even with 50,000 clients - try to make it with a regular RBMS. We setup backup and replication in our framework for SQLite3 backup. As you stated, using an ORM like the one in mORMot would allow to switch to another DB, even a NoSQL one like MongoDB, with no code modification. But from all our tests, SQLite3 was the fastest when building MicroServices - i.e. Services which require a local storage.

It is a perfect match for mORMot + SQLite3. But I am biased for sure! 😄 You may even use easily one database per account, if you wish too... this ease maintenability and scaling a lot! And eventually you would be able to use FPC to compile your server application for Linux, if you need to. Performance will be much higher than with FireBird or other remote DB, and SQlite3 is perhaps the most well tested DB ever. https://www.sqlite.org/testing.html We use it on production with DB of dozen of GB, with no problem - and it usually uses much less disk space than FireBird for instance.

As backend, consider SQlite3 as a local database on the server side. It is perfect for such service storage. There are several SQLite3 libraries for Delphi, from FireDAC to Zeos/ZDBC or mORMot. In your code, if you don't know anything about SQL, consider using an ORM like Aurelius or mORMot to work with objects, and not SQL.

I just published a blog article about how to write clean code, and also high-performance code. http://blog.synopse.info/post/2018/11/12/EKON-22-Slides-and-Code These were sessions at latest EKON 22 conference in Germany: we were more than 140 Delphi developers! Hope this helps!

@Stefan Glienke Seems indeed like it was not part of it. 🙂 See https://www.cs.utexas.edu/users/novak/grammar.html

Perhaps the other way around: let strong typing be OFF by default (backward compatible) but enable it to ON for new code requiring it. 🙂 About Unicode/AnsiString it was a requirement due to another breaking change.

@Kryvich Changing the compiler requirements on such would break backward compatibility. This is why I doubt it would happen. Another problem is about the overloaded functions. The compiler will complain about ambiguous usage, and will abort compilation. And another is about type helpers: it is for a given type, so you can't use double.ToString as TDistanceMeters.ToString IIRC. I complained against that when they introduced type helpers - I guess noone at EMB uses user defined simple types (whereas I use it everywhere). @David Heffernan Defining records is indeed the proper way of ensuring very strong type checking. Especially with the implicit conversion introduced with Delphi 10.3. And you would gain methods, e.g. for making conversions explicit (which is even better). But in practice, I like the fact that "type double" gives at least some information in the IDE (e.g. code completion) which is not needed to be put as parameter or function name.

Yes, camel-casing or using commas are options. Since some of the code is expected to run on Delphi 7 (for several convenient reasons, no technical ones) we didn't use comma. But the point of the proposal was that we won't use the project name, but the *folder* name within the unit name, to ensure 1. that the file is easy to locate in the SCM or at file level 2. the folder logic is not about projects, but to ensure data/ui/projects/etc... are uncoupled. Folder layout, therefore unit name layout, therefore the system architecture, should not be project-oriented, but domain-oriented - see https://martinfowler.com/tags/application architecture.html