Leaderboard

Most likely this: https://quality.embarcadero.com/browse/RSP-30870

I should have been clearer. I'm talking about the new code they added for themed apps. I agree it is necessary for old pre comctl32 v6 apps. I still do that. For comctl32 v6 I can't understand why they don't use PARGB32 images.

I’ve just read this, which may be useful for the question: Remove: <uses-permission android:name="com.android.vending.BILLING" />from AndroidManifest.xml in android app folder. Since Nov 1st Google count that as a sign of V2 billing library and does not approve releases.

16 colors ought to be enough for anybody? 🙂

I'm refactoring usage of various different look-up tables and I'm trying to come with 1 fast look-up table design. Most of them have 1 thing in common: search by integer (ID) and search by string (Name). All data is sorted. So, I bench-marked TArray.BinarySearch, TDictionary and custom binary search. Even though a flaw in design was pointed out for TArray.BinarySearch, (see https://en.delphipraxis.net/topic/4575-why-is-tarraybinarysearch-slower-than-normal-binary-search-function/), I still wanted to compare results: For search by integer, custom binary search seems to be a little faster than TDictionary, until large tables: For search by string, custom binary search wins even more, still for not large tables: Interesting is that for smaller searches, 10 records, a sequential search is faster than TDictionary. I also tried TGpStringHash (by Primoz Gabrielcic), which is very fast, but unfortunately no implementation for integers. TSynDictionary (from mORMot) is also very fast, but I don't use mORMotand license is not friendly for my commercial project. Is there any other fast search implementations that is not too specialized and ready to use out of the box, that I can try?

Hello World, I just had a pleasant surprise - when I build a certain x64 project of mine, the executable is noticeably smaller under Delphi 11 Alexandria (6.5 MB) than under Delphi 10.4.2 Sydney (7.3 MB). Embarcadero must have done some serious optimizations. (Edit) the project is compiled with {$WEAKLINKRTTI ON}.

Come on what about the way they've changed the high dpi support (it's almost working.).

Need a hug? 🙂

I think even back then people were complaining that Delphi exes were too big. It's not that I can't see the beauty of small executables (I envy the size of an exe produced by a C program using only the standard libraries), the size just hasn't been a priority in what I used Delphi for for a few decades.

But you would be in "Delphi Heaven", not "DLL Hell".

While it is a nice thing for some, ever since the use of floppy disks for data exchange has dwindled, the broader audience does not really care about exe sizes.

It has always been a mistake for Embarcadero to owner draw menus when they have images. I modify the rtl to avoid this and let the system drawn the menus, using PARGB32 images. After about 4 or 5 delphi releases they got their owner draw code to mostly work as well as letting the system draw it, although I think there were still DPI scaling issues. But it was inevitable that a new version of Windows would mean that owner draw code needed updating. And any applications out in the field would be stuck with this owner draw code that hasn't been tweaked for the new Windows version. It makes no sense to me that they did this. Surely the entire point of the system theme is that the system draws it.

The Jcl project analyzer shows the largest differences in size to be in the following units. But there are small size reductions in many other units (rtl and mine). Delphi 10.4 Size Delphi 11 Size2 Diff Vcl.Themes 292380 Vcl.Themes 215,944 76,436 System.Classes 360524 System.Classes 314,652 45,872 SVG 124584 SVG 87,720 36,864 System.Threading 119156 System.Threading 87,640 31,516 System.Rtti 219480 System.Rtti 191,064 28,416

If you plan on doing this with a mobile phone then just turn the chair around and record the person against the live background... It's called a selfie I hear 🙂

Synopse documentation builder has some of this built-in which might help... not sure how standalone it is. @Arnaud Bouchez

Yes. Delphi 11 shipped with the latest Indy that was available 3 months ago.

IIRC, Andy has been offered a free license at least twice, but he reclined.

We can certainly argue over the term "big" - but performance is either CPU or memory bound - and with hash table items be scattered all over the heap it most certainly will be memory bound. Hash tables are complex beasts and there are many considerations when designing one but usually, you want to avoid blasting your items all over the heap. Interesting read: https://leventov.medium.com/hash-table-tradeoffs-cpu-memory-and-variability-22dc944e6b9a

It's an improvement on a Trie. The Dr Dobbs article (still on line at https://www.drdobbs.com/database/ternary-search-trees/184410528) claims in their Conclusion, "Ternary search trees are efficient and easy to implement. They offer substantial advantages over both binary search trees and digital search tries. We feel that they are superior to hashing in many applications.". See also:

No surprise there - linear search is O(n), binary search is O(log n) and hash table is O(1), what you see with the differences for certain number of records are the different constant factors - building a hash has a certain cost which is why TDict is slower up to a certain point - this depends on the hash algorithm being used - indirections being caused by extra function calls like IEqualityComparer.GetHashCode and the memory layout of the hash table. You can even see that it's not strictly O(1) as it gets a little slower the more records you have which I would guess is due to memory layout within the hashtable where at a certain point memory access time kicks in because the data does not fit in the fast cache anymore (access pattern of the benchmarking code matters there as well). Without specifying the exact use cases it's hard to give any suggestions - is the data one time fill and then only lookup, is data being changed after - adding/removing records, is data within the records changing. Whats the typical lookup pattern - is data being looked up randomly or in certain patterns (such as ID or Name sequences in certain order). If you aim for maximum performance a custom data structure and algorithm will always win over some standard algorithm by a few percent - the question is if you want to do all that work including risking bugs for that negligible few percent or use some standard data structures and algorithms that are proven to work and easy to be applicable.