If you are into Borland Delphi somehow, you probably already know what FastMM4 is. But for those of you who have no idea what I’m talking about, I give a short explanation.
In Delphi applications, you have a so called memory manager which is responsible for allocating and deallocating memory. By default, Delphi applications use the standard Borland memory manager (or BorlandMM for short) which is included in Delphi. BorlandMM is fine for most cases but unfortunately has a few problems (mainly memory fragmentation and with heavily multi-threaded applications). The good news is that in Delphi the memory manager isn’t a hardwired, irreplaceable thing. In fact, you can replace the default memory manager with a different memory manager of your choice simply by replacing a dll or adding a single file to your project.
These two facts (suboptimal and easy-to-replace default memory manager) led to a few alternative memory managers in the past, both commercial and open source. In this set of managers, one of the most popular is the mentioned FastMM4, an open source and “lightning fast” memory manager written by Pierre le Riche. There has been a lot of discussion about FastMM4 in the Borland newsgroups and within the Delphi community lately, simply because it seems to be so much better than the default memory manager. Well, and since even Borland will ship the next Delphi with FastMM4, I decided to give it a try.
The SmartInspect Console has one area where the BorlandMM looks, well, improvable. This area is the multi-threaded TCP server part of the Console which is responsible for receiving logging information from the SmartInspect libraries. The performance of the BorlandMM is fine in normal cases, but is getting worse the more clients are connected and the more log entries have been received. I suspect this is due to memory fragmentation and BorlandMM’s problem with multi-threaded applications in general. Don’t get me wrong, the performance is still ok and you need to have a lot of log entries (by far more than 100k) to enter this stage, but it’s annoying for me nonetheless.
Therefore, I’ve been glad to read the FastMM4 documentation and to see that exactly these two main problems of BorlandMM do not occur with FastMM4 (”scales well in multi-threaded applications, is not prone to memory fragmentation”). And as it turned out, the documentation is more than right. The performance increase after integrating FastMM4 is really impressive. It doesn’t matter anymore how many clients are connected and it seems that the memory fragmentation is gone, too. The performance increased up to 100% in some cases. Really wonderful piece of software.
But despite the good first impression and the fact that other companies already use FastMM4, it will not be included in the upcoming SmartInspect 1.2 release. I expect the 1.2 of SmartInspect to be released this month and such a dramatic change as a memory manager replacement needs to be tested carefully. However, if we don’t encounter any problems, I expect FastMM4 to be a part of the SmartInspect Console quite soon.
Recent Comments