Memory managers revisited

[Alexandre Machado]

Hi guys,

I was doing some performance measurements using a really wide range of Delphi compilers and I decided that I'll write a more complete blog post showing some results and discussing the memory managers available to Delphi users. It's not ready yet, but it will be soon.

Anyway, until then, I'd like you - Delphi/IntraWeb developer - to open your IntraWeb project and double check what is the memory manager that you are currently using.

The results that I obtained testing different memory managers are shocking!! Here's the result of one test case:

- Delphi default MM (based on FastMM4): 13K req/s
- FastMM 4 with std options: 10K req/s
- FastMM 4.992 (options included with IntraWeb installer): 30K req/s
- MSHeap: 43K req/s
- FastMM 5: 44K req/s
- ScaleMM2: 45K req/s

Forget minor differences now and focus on the most important thing:

If you don't use any memory manager other than the Delphi built-in (based on FastMM4) or you are using an older version of FastMM4 (anything other than 4.992), your IntraWeb application is probably limited to 1/3 of its real capacity, due to the limited capacity of the old MMs to handle memory allocation/deallocation in a multi-threaded application 

More on it to come, but for now, check your source code and fix it right now. I'd recommend you to start with the version of FastMM 4.992 that can be installed with IntraWeb (it's the exact same version that you can find on Github but we configured the options to give you maximum performance in production).

Cheers

[iwuser]

Hi guys,

I was doing some performance measurements using a really wide range of Delphi compilers and I decided that I'll write a more complete blog post showing some results and discussing the memory managers available to Delphi users. It's not ready yet, but it will be soon.

Anyway, until then, I'd like you - Delphi/IntraWeb developer - to open your IntraWeb project and double check what is the memory manager that you are currently using.

The results that I obtained testing different memory managers are shocking!! Here's the result of one test case:

- Delphi default MM (based on FastMM4): 13K req/s
- FastMM 4 with std options: 10K req/s
- FastMM 4.992 (options included with IntraWeb installer): 30K req/s
- MSHeap: 43K req/s
- FastMM 5: 44K req/s
- ScaleMM2: 45K req/s

Forget minor differences now and focus on the most important thing:

If you don't use any memory manager other than the Delphi built-in (based on FastMM4) or you are using an older version of FastMM4 (anything other than 4.992), your IntraWeb application is probably limited to 1/3 of its real capacity, due to the limited capacity of the old MMs to handle memory allocation/deallocation in a multi-threaded application 

More on it to come, but for now, check your source code and fix it right now. I'd recommend you to start with the version of FastMM 4.992 that can be installed with IntraWeb (it's the exact same version that you can find on Github but we configured the options to give you maximum performance in production).

Cheers

Alexandre,

Very interesting, thanks!

Is this on physical hardware or running in a VM? - if the former, can you re-run this and publish the numbers for the latter, or vice versa?

VM's are typically much slower with context switches and memory operation, so there should be a huge difference.

Is this standalone, using Indy? - would you please re-run this and publish the numbers for 1) ISAPI and 2) Http.sys?

Hopefully, both of these should be faster. But it would be interesting to have comparable numbers.

Also, how many CPU cores / threads did you have here for this test? - it should have impact on the magnitude of the default MM vs. ScaleMM difference, i.e.: if it's 1:3 with 4 cores, it could well be 1:30 with 64 cores.

[Alexandre Machado]

These numbers were obtained running on a real machine with 14 cores. I'm using an Indy server and the test tool used is jmeter.

There is a "problem" with this test which is, both server and client are running on the same machine, something that tends to affect the results. When I publish the real thing, I'll be redoing the tests using 2 different machines on a network. Also, this is an Indy app that is basically only testing the http server itself.

The main goal was to show how the memory managers deeply affect the performance and picking one may be hard sometimes (you always want the best performance, sure, but memory usage may vary - and it does - a lot from one MM to another).

Regarding Indy/ISAPI/Http.sys, what I can tell you now is that Http.sys is faster than Indy, as expected btw. But Indy doesn't perform bad at all. Actually I was gladly surprised with Indy's performance, especially considering that part of the Delphi community usually curses Indy performance (the fame worsened after a developer named Roberto Schneider published a performance comparison many years ago, which I particularly found poorly executed).