Arnaud Bouchez

It is also known as "stupid sort". Best algorithm name ever.

I don't agree. This is highly depending on the DB itself. A count(*) could take a lot of time for a huge database, or with a complex query with no proper indexes. You could have a count(*) of a few rows (e.g. one or two rows) which takes a lot of time on big tables with a SQL request bypassing the indexes. In this case, it is better to retrieve the few result rows instead of making a select count(*) following by a select *

You may either: Refine your SQL query, e.g. by adding some proper indexes to the DB, to make it faster on the server; Actually retrieve all data at once (maybe into an in-memory list/array), but use Application.ProcessMessages within the loop to avoid UI freezing; Don't care about exact record count: just fetch the first 1000 for instance, and write '>1000' on the UI if there are more rows.

As I wrote it never stores a double - SQLite3 doesn't support TDateTime double which is Ole/Windows specific. In your code, text will be stored. It is because that SQliteStudio display what is stored, i.e. text, trying several date/time layouts. It seems that FireDac expects ISO-8601 encoding - just as SQLite3. And don't forget to set the seconds - even :00.

IIRC, SQLite3 has no native date/time format, but it can understand ISO 8601 text fields and Unix Epoch integer fields.

Thanks for the detailed feedback... from the asm sounds like a compiler issue. It may be worth a ticket, since it may affect not only our code, but a lot of it!

From a Github issue description for our SynPDF Open Source project: Generating a PDF via VLCCanvas and TPdfDocumentGDI causes access violation when compiled with Delphi 10.4.1 with record field alignment compiler option set to "byte" or "off". When this option is set to either of "word", "double word" or "quad word", the PDF gets created without errors. The same exact code works fine when compiled with Delphi 10.4 (patch 3), regardless of the field alignment flag. We added {$A+} and it seemed to fix the problem. https://blog.synopse.info/?post/2020/09/09/Record-Alignement-and-Delphi-10.4.1 Sadly, I don't have access to Delphi 10.4.1 since I don't have any commercial licence, and I am waiting for the Community Edition - which is still 10.3 IIRC. So I couldn't debug the root cause and fill a JIRA ticket to EMB. Perhaps some people from Delphi-Praxis may have encountered this issue, and found the root cause... Maybe it is was a real fix introduced in 10.4.1, and the previous behavior was incorrect: perhaps an explicit {$A+} is required when working with records... but at least, it breaks existing code, so spreading the info may help...

I wonder if the WebSockets encapsulating in HTTP/2 makes a huge performance difference in respect to plain HTTP upgrade. Speaking about WebSockets frames communications, not HTTP requests.

This is the main idea. No premature optimization. This is not because a single line ("case ... of") is slightly faster than your work will be faster. AnsiString with the system code page is a wrong idea - it is not able to store all Unicode content. UTF-8 is a good idea if you use it from one end to the other in your project. For instance, if your database layer uses "string" then using AnsiString won't help. On the contrary, conversion and memory allocation has a cost, so it may be actually slower. Only if you have UTF-8 from end to end, e.g. in our Open Source framework, we use UTF-8 everwhere, e.g. from DB to JSON, so no UTF-16 conversion is done. It is perfect for server side. But if you write a VCL/FMX RAD app, using plain string makes more sense.

We can report that a compiler regression about wrongly optimized result value was fixed with 10.4.1. https://quality.embarcadero.com/browse/RSP-30088 Even if it has been reported in JIRA as "Expected behavior". 😞 https://synopse.info/forum/viewtopic.php?pid=32966#p32966

Cross-Platform was prepared, there are OS-specific units, but the POSIX versions were never finished nor tested IIRC, since Eric (the maintainer) didn't need anything outside Windows. As stated by Eric in his blog https://www.delphitools.info/2018/04/20/dwscript-transition-to-delphi-10-2-3/#more-3949 : Darwin/Linux support may be feasible, but Mobile platforms would require some ARM low-level stuff, which may not be easy to do.

DWSScipt is my favorite. Its syntax is modern, and its implementation is very clean. It even has a JIT! The problem is that it is not cross-platform yet. The veteran PascalScript is my favorite if cross-platform is needed. It is stable, and widely used since years.

Not that I have seen. You can run Delphi 7 with non-admin rights, as soon as you install it not in "c:\program files". This did not change since Vista.

I don't see Delphi 7 being slow on Windows 10, with the built-in antivirus/antimalware. I installed it in a c:\Progs\Delphi7 folder, not in the default "c:\program files" sub-folder. Ensure you installed https://www.idefixpack.de/blog/ide-tools/delphispeedup/ tool.

On Windows, we use http.sys kernel mode which scales better than anything on this platform. It is faster than IOCP since it runs in the kernel. On Linux, we use our own thread-pool of socket server, with a nginx frontend as reverse proxy on the unix socket loopback, handling HTTPS and HTTP/2. This is very safe and scalable. And don't trust micro benchmarks. Even worse, don't write your own benchmark. They won't be as good as measuring of a real application. As I wrote, Intel TBB is a no-go for real server work due to huge memory consumption. If you have to run some specific API calls to release the memory, this is a big design flow - may be considered as a bug (we don't want to have the application stale as it would have with a GC) - and we would never do it. To be more precise, we use long-living threads from thread pools. So in practice, the threads are never released, and the memory allocation and the memory release are done in diverse threads: one thread pool handles the socket communication, then other thread pool will consume the data and release the memory. This is a scenario typical from most event-driven servers, running on multi-core CPUs, with a proven ring-oriented architecture. Perhaps Intel TBB is not very good at releasing memory with such pattern - whereas our SynFPCx64MM is very efficient in this case. And we almost never realloc - just alloc/free using the stack as working buffer if necessary.