FastMM is a wonderful memory manager, but it can slow down quite a lot when used in multithreading environment. While Pierre has implemented some conditional defines that could help the multithreaded code, namely NeverSleepOnThreadContention and SwitchToThread, I’m now making a point that you shouldn’t ever use them! Just see for yourself.
Below is a performance graph of some service I’ve wrote. During the testing, it was running 9 very active threads (but none of them was CPU intensive, they spent lots of time sleeping) on 2 cores (limited down from 8 for testing).
Given the amount of data the application is processing (three DVB inputs with 80 Mb/s on each) the CPU usage is not high at all.
Compiled with /dNeverSleepOnThreadContention (and regardless of presence of /dSwitchToThread), the performance graph goes wild.
Those CPU spikes go to 100% for about 5 seconds!
Looking at the application in Process Explorer I can say that about 6 threads want to do something with the memory at the same time and NeverSleepOnThreadContention code goes berserk and spends many seconds in a tight loop.
This is, of course, the nice version of the story without the PG rating. In reality the trouble started at a customer and we had absolutely no idea what’s going on – sometimes the input and output would start stuttering and software would complain that there’s no input connected and that it cannot transmit. After quite some time I managed to repeat the problem in the lab but still I had no idea what’s going on. I spent two days looking for problems in my code before I spotted the real culprit. And then I spend two days cooling off so I could write this story without a bunch of expletives.
The moral? We really need a good multithreaded memory manager. I know that there are ScaleMM and SynScaleMM and TopMM but as far as I know the first two are still not bug-free and the third is a real memory hog. And I really love all debugging features FastMM has built in.
As the Embarcadero has no interest in hardcore Windows programming anymore, I don’t think we can expect them to step ahead and pay somebody do improve FastMM. Maybe we (as community) can convince Pierre to do the work? Would you donate some hard earned cash to get better FastMM? I did it before just to tell Pierre that his work helped me a lot and I would gladly do it again.
Update 2011-10-13: See also http://delphitools.info/2011/10/13/memory-manager-investigations/