Alex7691

Thanks. Responding to your questions: a) The only metrics I have is the size of the executable. Using Rapid.Generics, I got a slightly smaller executable. b) Most of these classes that you mentioned are not necessary for most containers (the sync objects are needed for the TThreadList<>, TThreadedQueue<>. But if you don't use them, Delphi smart linker won't include them.

Hi Stefan, In our application there is a notification bus which internally has 2 dictionaries. The main one has an object (the "observable") as the key and a list of objects (each object has references to observers and notification methods) as the value. The second dictionary also has an object (the "observer") as the key and and Integer as the value. The dictionary may contain a large number of objects (dozens of thousands) and at some point in time all the objects need to be freed. So when ObjA (an observable) is being destroyed it will notify all it's observers. Then it will remove itself from the dictionary and all oberservers will also be removed if they are only observing ObjA. This is where the new dictionary performance surprised me. The notification happens faster (because retriving the values from the keys is faster), but more importantly removing them from the dictionary is way faster than the previous version based on std TDictionary.

Tested using Win32 and Win64 compilers only for now. Android and Linux, it's possible in a near future. Not sure if I'm going to test on any Apple OS, though... Not into MacOS/iOS dev myself. FMX and VCL are UI frameworks and don't have any relevance for the testing.

It has also been fixed in the lastest version in github repo. Cheers,

True thing. Please update the source code from github repo. It's fixed now and there are a few new test cases to cover TObjectList (tests for TObjectList are not complete yet). Thanks

As I said, it started more like a curiosity... like "it's so damn fast, but it's buggy... Can it be fixed to the point of being useful?" And after "wasting" the weekend, here I am

Yep, Rapid is a drop-in replacement. Actually my code now has: uses {$IFDEF USE_RAPIDGENERICS} Rapid.Generics, {$ELSE} System.Generics.Collections, System.Generics.Defaults, {$ENDIF} I can just toggle this compiler directive globally and the 3+ MLOC application can be built either using Rapid generics or std System.Generics.Collections, which is a major bonus. At anytime I can just switch this off with minimal impact (e.g. let's say EMB releases a new faster System.Generics.Collections in Delphi 12+x?)

Hi Stefan, yes, I know that Spring4D is great but it would be impossible to refactor hundreds of occurrences of different data structures in a massive 3+ MLOC application... Rapid.Generics took me no more than 2 or 3 hours do change the application (of course, excluding many hours devoted to fix the library itself, but I was mostly doing it for fun in a "let's see if I can make it work" spirit). Basically I needed to do a grep seach/replace + a handful of tweaks here and there and voilá... it was building.... Cheers,

Hello everyone, Last week I (unsuccessfully) tried to use the Rapid.Generics library in a specific project. After replacing the std TDictionary/TList with the Rapid.Generics equivalents, the application fell apart within the first 10 seconds of testing, which was quite disappointing. Having some spare time during the weekend, I decided to give it a shot and see if I could make it work properly, at least fixing the most important and visible issues. As a result, I am now sharing my changes so others can benefit from them or contribute. https://github.com/Alexandre-Atozed/Rapid.Generics.v2 Improvements (Readme contains a more detailed list): Fixed multiple bugs Refactored and streamlined the code Removed some unused code Added 123 unit tests, creating a comprehensive test suite The modified code passes all tests and is also free of memory leaks. The real world application is being tested with it now and the initial results are promising. One specific scenario where I replaced the std TDictionary with the Rapid.Generics one (a notification bus where a dictionary is used to map the instances) had a performance increase of 10x or more which is beyond what I would expect and too good to ignore. Any feedback or contributions are welcome! Cheers,

I have a huge application in production using VCL Styles and the package mentioned above: https://www.almdev.com/prods/stylecontrols/stylecontrols.html The adapter works well with DevExpress grid and other controls like their different tree views. That's all we use from them. We decided to use other StyleControls components (buttons, date editors, page controls) instead of DevExpress ones because: 1) they play well with VCL Styles 2) Their code is much simpler and in general any issue you find can be fixed by yourself in a couple of hours (compared to days to impossible to fix in DevExpress). It's clear that the author just wants to create something that does its job and works well, instead of trying to use every single pattern in any Gang of Four book. 3) They are lightweight insted of the Dx famous kitchen-sink design I strongly recommend it if you are going down the VCL styles route (disclaimer: I'm not related to almdev company) Cheers,

Has anyone had any luck with Tiny.Library (https://github.com/d-mozulyov/Tiny.Library), more specifically with its Generic classes? BTW, Rapid.Generics contains an older/simpler version of its Tiny.Generics unit (https://github.com/d-mozulyov/Rapid.Generics) I did a quick test on a TDictionary and the performance is impressive compared to the standard System.Generics. Collections dictionary. However, some other tests with TList<> , for example, showed random errors that were difficult to identify the cause, such as exceptions in ReallocMem(). In addition, I identified some bizarre bugs in the code, such as in the TArray.InternalSearch() method, see below: class function TArray.InternalSearch<T>(Values: Pointer; Index, Count: Integer; const Item: T; out FoundIndex: Integer; Comparer: Pointer): Boolean; var I: Integer; Helper: TSearchHelper; begin if (Count <= 0) then begin if (Count = 0) then begin FoundIndex := Index; Result := True; <---------- The result cannot be True when Count = 0 Exit; end else begin raise EArgumentOutOfRangeException.CreateRes(Pointer(@SArgumentOutOfRange)); end; end; System.Generics.Collections has a similar code and the result is obviously false: class function TArray.DoBinarySearch<T>(const Values: array of T; const Item: T; out FoundIndex: NativeInt; const Comparer: IComparer<T>; Index, Count: NativeInt): Boolean; var L, H, mid: NativeInt; cmp: NativeInt; begin if Count = 0 then begin FoundIndex := Index; Exit(False); end; I wouldn't expect to find this in a library of this level, unless it has never actually been tested/used. The lack of unit tests is also concerning....

I ran some benchmark applications this week and I found out that the servers built with Delphi 12 are 13-16% faster than the same built with Delphi 10.4. I can't currently pinpoint the exact source of the performance gain but I guess that Move() and others are playing an important part on it. Anyway, very well done! Cheers,

Seems that you are referring to the TMainMenu control. We don't use it in our application. We used the TActionMainMenuBar which renders the menu. Not sure how much code they share and if the same problem affects both, but IIRC, the menu rendered correctly on high DPI monitors and in mixed setups. One thing that's really messed up in TActionMainMenuBar is the customization at runtime via TCustomizeDlg, and it happens all the time regardless of your monitor DPI. I've reported the issue to EMB but no fix so far: https://quality.embarcadero.com/browse/RSP-31714 Other than that we haven't found any major issues so far.

We tested the application in a mixed monitor setup and it behaved in an acceptably manner (built with 10.3.3). I'm not saying that it is perfect. I'm saying that we couldn't find any showstopper issue. But I also found issues with several other applications in the same scenario, including WPF ones. I think MS didn't get it perfect either. As I said, the application has thousands of users around the world and the general feedback has been good. Nobody ever said that "it doesn't look prefessional" because of some minor issue like this.

That's an old post but since I don't come here often, here it goes: David, you are wrong. IntraWeb is not one decade old. IntraWeb was introduced in 1994, as a product, before Delphi 1.0. In the Delphi world it is as "old" as Delphi itself. And IntraWeb's doing fine, for 30 years, thank you. I dare you to name another product/framework that started before IntraWeb and is still around. And, no, DevExpress and TMS were both founded *after* Atozed and IntraWeb. The same argument that you use against IntraWeb is the one that a Python developer uses against your application that you wrote in Delphi: "Hey, nobody uses Delphi anymore!". The Python developer will never get it, simply because he doesn't know it. Cheers