There has been some speculation into the recent Delphi Roadmap announcements regarding the inclusion of FastMM4. Some have speculated that this memory manager is only use for the IDE. Well, that is simply not true. FastMM4 is now the default memory manager in the Delphi RTL. It wholly replaces the existing Delphi memory manager and will from now on be included in any Delphi Win32 application compiled with DeXter. Yes, the IDE also uses this new memory manager and in fact, by simply replacing the memory manager in my informal tests I saw the IDE startup time drop from 25 seconds to 13 seconds... folks that is nearly a 50% increase in performance!
One thing to note about this move is that it highlights the unique relationship the Delphi Development team has with its customers. There are very few products in almost any industry that has this strong of a community. It is the commitment and tenacity of the Delphi community that helps make things like this happen. So, be sure to support Pierre le Riche, the author of FastMM4, in his endeavours. For my part, I'll be ensuring that he receives a complimentary copy of next version of Delphi... I'll also be looking into making sure he gets a copy of each version from now on as well.
Is it possible to replace the default memory manager in Delphi 5 with FastMM4 ?
ReplyDeleteIf so, how would I do this ?
grant@sitedoc.com.au
Regards Grant Brown
Borland should use the PayPal button very often ... :-)
ReplyDeleteGrant: it's easy, just add a reference to the FastMM unit as the first unit in the uses of your project.
ReplyDeleteFor more details, extensive doc is included in the FastMM zip.
Oh, and as a reminder, if you get crashes with FastMM, don't suspect it, suspect your code. FastMM is not only faster but stricter, old MM would "ignore" some mismanipulations, resulting in potential memory corruption or "random" bugs rearing their ugly head much later in the application's execution.
"For my part, I'll be ensuring that he receives a complimentary copy of next version of Delphi... I'll also be looking into making sure he gets a copy of each version from now on as well."
ReplyDeleteThis is great news for a very valuable donation to the Delphi community. One of the things I love most about Delphi is the peer support network. Pierre's put a lot of effort into this and I'm really happy that he's been acknowledged for his work.
"For my part, I'll be ensuring that he receives a complimentary copy of next version of Delphi... I'll also be looking into making sure he gets a copy of each version from now on as well."
ReplyDeleteWow, thank you! :-)
Hi Allen,
ReplyDeleteI only can write would was said. If I would write more John would come by and slap the NDA across my face ;-) (Good that it is known that I have signed this, so no breach in writing that here <g>)
Well, Pierre - you deserve it - for sure!
ReplyDeleteWill FASTMM4 as implemented in Delphi 10 be able to run in full debug mode like the current FASTMM4 allows?
ReplyDeleteI hope for a resource leaks window showing stack traces for each memory problem. Right now FASTMM saves this in a plain text file, but it would be very nice if double clicking on a stack entry would just show me the exact location in the Delphi code editor.
Get your math right.
ReplyDeleteIt is nearly a 100% increase in performance, ie the performance nearly doubled.
Hmm, tried to use it in our app which consists of a number of runtime packages (all statically linked), several COM DLLs (would I need to use the SharedMem stuff for those? I never did so far) and the main executable. I put FastMM4 into all the DPRs' uses clauses and activated the UseRuntimePackages option. All seems fine but when I close the app I get a report of a few leaks (all of which MemProof does not report) and then an endless loop of Application Errors ("The instruction at "0x40009548" referenced memory at "0x01334e50". The memory could not be "read".") and access violations in rtl70.bpl . I also get about 600k worth of leak reports in the text file, most of which I have no real explanation for.
ReplyDeleteWhat am I missing? Or better yet: what's the better place to discuss such issues?
The only unique thing is that it took you 10 years to replace the crummy default memory manager. It's not as if it was ever a secret that it didn't perform.
ReplyDelete"...get a report of a few leaks (all of which MemProof does not report) and then an endless loop of Application Errors..."
ReplyDeleteOliver, it sounds like a package unload order problem. The fact that you get a huge leak report followed by a lot of A/Vs suggests that FastMM is uninstalled before all live pointers have been freed. You can either ensure that FastMM is unloaded last (using sharemem together with the replacement borlndmm.dll is one way), or you can use the "NeverUninstall" option and disable the memory leak report.
Contact details are in the source file if you need further assistance.
BillG,
ReplyDeleteYep that's right.. we're a bunch of worthless slugs that couldn't program our way out of a paper bag... I've gone over and over this more time than I care to count, but while the old memory manager had some shortcomings, it was far from "crummy". I suppose thousands upon thousands of applications successfully using it over the years with great success doesn't count... my, my, how history has changed.
Oliver,
ReplyDeleteThis isn't really a tech support forum. You'd certainly be much better served by visiting the Borland newsgroups for assistance.
Good Stuff!
ReplyDeleteHas anyone fully tested FastMM for reliability under high-stress multithreaded DLL-based servers? Particularly where multi-core and HT is concerned?
ReplyDeleteAllen: Does the FastMM4 unit become 'invisible' under DeXter (just like the current RTL-MM blends in 'anonymously' in the RTL), or will it be included as a distinct source unit in its original form from Pierre's Sourceforge site?
ReplyDeletePierre: Congratulations!
Jake: it's out there in the field for us now under very stressing conditions... doing its big magic 24/7. Highly multithreaded TCP servers running on dual-core and HT systems. No DLL's though.
It amazes me that anyone could complain about the memory manager in either TP, BP or Delphi.
ReplyDeleteThe default memory manager was designed for the large number of mid-sized allocations typically performed by a business application.
The only possible complaint anyone could have about it is that it hasn't scaled well in multiple processor environments, but Windows hasn't traditionally scaled well either until recently. And that is still debatable.
Borland's open RTL made it possible that memory managers such as FastMM could be written and plugged in with minimal effort. Anyone experiencing any kind of problem with the default manager could easily replace it. Try that with most other compilers!
Complaining is our solemn duty! ;-)
ReplyDeleteThe Delphi MM has simply aged. It was designed when a normal app only had a few hundred KBytes and allocated only a few megabytes.
The IDE of D2005 is several times as big as the IDE of D6.
"Borland's open RTL made it possible that memory managers such as FastMM could be written and plugged in with minimal effort."
ReplyDeleteCorrection:
"Borland's open RTL made it possible that memory managers such as FastMM could be written and plugged into Delphi with minimal effort."
Try that with C++ Builder. Especially with Run-time packages.
Adding to Skaug question: will FastMM's options tightly integrated with the IDE - I mean, setting the switches via the IDE instead of several defines, and the debug features too?
ReplyDeleteHaving tried FastMM with Delphi5 and 2005, all I an say is "WOW" its a great addition that it will be there as default rather than a thing people have to know to go and find!
ReplyDelete*hugs* to all
I suppose a free version of Delphi is cheaper than paying him the salery he would have been due if he did the work as an employee of borland over the same period of time.
ReplyDeleteJust imagine the savings if you could convince someone to write the IDE for a free copy too. Mind you, since that might mean a more stable IDE with a wider set of features, perhaps it is an idea whose time has come.
Mr. Johnson,
ReplyDeleteYou certainly seem to enjoy throwing around insults and accusations without the benefit of all the facts. I can certainly appreciate that you are entitled to your opinion, but I do find your blind insults a bit tiresome and boreish.
From my perspective, being able to leverage talent and abilities in the community helps to further foster a generally "inclusive" feeling throughout. This isn't an "us" vs. "them" kind of thing.
You also seem to be under the impression that we took Mr. le Riche's MM because of our own internal inability to create similar technology. This is simply not true. Why re-invent the wheel? Why not have Borland engineers focus on those things that *only* Borland can do?
we certainly seem to disagree here (on a wide number of points), and discussing them would just devolve into a flame war.
ReplyDeleteLet me ask you this rhetorical question:
Why didn't Borland improve the memory manager years ago, before the third party offerings were developed to make up for the poor performance?
No need to answer, I won't be reading your blog again, but you might want to think about that question long and hard. Apply the same logic to other similar areas as well - after all, developers are basing their livelyhoods on borland's ability to deliver stable products and maintain them as times go by.
Open source? in a corporate development production piece of software? Sounds tacky to me frought with potential legal issues. I would venture to say that VS doesn't use open source projects but rather purchases the technology or otherwise steals it legally thus "owning" the piece of work being discussed and thusly responsible for it working. JMHO. Open source would be okay for use in a app developed by a trucking company.
ReplyDeleteHumm interresting but, in our case we already use another unit called FastShareMem, does someone have ever did some test to compare both of them.
ReplyDeleteThanks.
Eric Lacroix,
ReplyDeleteFastShareMem is just an improvement over borlandmm.dll way of supporting Variants and AnsiStrings in non-BPL DLLs. It doesn't improve "normal" memory management.
"Oh, and as a reminder, if you get crashes with FastMM, don't suspect it, suspect your code."
ReplyDeleteDespite all other of virtues FastMM4, this statement proves not true.
I would like to know if there's a way of using the old memory manager with Delphi 2006 (Dexter). I have an old project that consists of many dlls and an executable coded with pure windows API for speed and small footprint. It uses aprox 3MB (Private bytes) when compiled with D7 or D9. When I compile it with Dexter is uses 10MB. If there's a way out of this please tell me. Thanks.
ReplyDeletegood
ReplyDelete