Rapid.Generics revamp

[Alex7691 13]

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,

Edited yesterday at 04:48 AM by Alex7691

[Stefan Glienke 2093]

You could have given spring4d a try, which is actively maintained 

[Alex7691 13]

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,

Edited yesterday at 07:33 AM by Alex7691

[David Heffernan 2406]

16 minutes ago, Alex7691 said:

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

And yet you did this with a other library? I'm curious. Why was it simple to integrate rapid? Does it have the same interface as rtl but is just faster? 

[Anders Melander 1952]

It looks to have the same interface but jeez it's a lot of code to maintain.

[Stefan Glienke 2093]

I was just curious. I expected the fact that it's a drop-in replacement to be a reason.

Rapid is quite an achievement and damn those collections are fast - I use them to challenge my implementation from time to time.

The design decisions are different, and for the extensive API of spring, I have to sacrifice a few nanoseconds here and there, as much as I dislike that 

[Alex7691 13]

10 hours ago, David Heffernan said:

And yet you did this with a other library? I'm curious. Why was it simple to integrate rapid? Does it have the same interface as rtl but is just faster? 

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?)

[David Heffernan 2406]

7 minutes ago, Alex7691 said:

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?)

Nice thought experiment

[Alex7691 13]

9 hours ago, Anders Melander said:

It looks to have the same interface but jeez it's a lot of code to maintain.

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 

[Anders Melander 1952]

14 minutes ago, Alex7691 said:

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?)

Nice!

Unfortunately I don't have any code where generics is anywhere near the bottleneck or I would have had a go with it.

[David Heffernan 2406]

13 hours ago, Anders Melander said:

I don't have any code where generics is anywhere near the bottleneck

That's not what this is about, generics being a bottleneck. The potential bottleneck is the RTL dictionary class. Which happens to be a generic type.

[Anders Melander 1952]

2 minutes ago, David Heffernan said:

The potential bottleneck is the RTL dictionary class. Which happens to be a generic type.

Thanks for explaining that to me. Now I understand everything exactly like I did before.

 

I don't have any code where anything in system.generics.collections or system.generics.defaults is anywhere near the bottleneck

Better?