The rumors are true...FastMM

Posted by on in Blogs

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.

About
Gold User, Rank: 84, Points: 11

Comments

  • Guest
    Grant Brown Wednesday, 28 September 2005

    Is it possible to replace the default memory manager in http://www.borland.com/delphi" target="_blank">Delphi 5 with FastMM4 ?



    If so, how would I do this ?



    grant@sitedoc.com.au



    Regards Grant Brown

  • Guest
    Peter Wednesday, 28 September 2005

    Borland should use the PayPal button very often ... :-)

  • Guest
    Eric Wednesday, 28 September 2005

    Grant: it's easy, just add a reference to the FastMM unit as the first unit in the uses of your project.

    For 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.

  • Guest
    Dave White Wednesday, 28 September 2005

    "For my part, I'll be ensuring that he receives a complimentary copy of next version of http://www.borland.com/delphi" target="_blank">Delphi... I'll also be looking into making sure he gets a copy of each version from now on as well."



    This is great news for a very valuable donation to the http://www.borland.com/delphi" target="_blank">Delphi community. One of the things I love most about http://www.borland.com/delphi" target="_blank">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.

  • Guest
    Pierre le Riche Wednesday, 28 September 2005

    "For my part, I'll be ensuring that he receives a complimentary copy of next version of http://www.borland.com/delphi" target="_blank">Delphi... I'll also be looking into making sure he gets a copy of each version from now on as well."



    Wow, thank you! :-)

  • Guest
    Daniel Wischnewski Wednesday, 28 September 2005

    Hi Allen,



    I 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>;)

  • Guest
    Gerhard Stoltz Wednesday, 28 September 2005

    Well, Pierre - you deserve it - for sure!

  • Guest
    Jan Derk Wednesday, 28 September 2005

    Will FASTMM4 as implemented in http://www.borland.com/delphi" target="_blank">Delphi 10 be able to run in full debug mode like the current FASTMM4 allows?



    I 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 http://www.borland.com/delphi" target="_blank">Delphi code editor.

  • Guest
    Robert Marquardt Wednesday, 28 September 2005

    Get your math right.

    It is nearly a 100% increase in performance, ie the performance nearly doubled.

  • Guest
    Oliver Giesen Wednesday, 28 September 2005

    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.



    What am I missing? Or better yet: what's the better place to discuss such issues?

  • Guest
    BillG Thursday, 29 September 2005

    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.

  • Guest
    Pierre le Riche Thursday, 29 September 2005

    "...get a report of a few leaks (all of which MemProof does not report) and then an endless loop of Application Errors..."



    Oliver, 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.

  • Guest
    Allen Bauer Thursday, 29 September 2005

    BillG,



    Yep 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.

  • Guest
    Allen Bauer Thursday, 29 September 2005

    Oliver,



    This isn't really a tech support forum. You'd certainly be much better served by visiting the Borland newsgroups for assistance.

  • Guest
    Dennis Landi Thursday, 29 September 2005

    Good Stuff!

  • Guest
    Captain Jake Thursday, 29 September 2005

    Has anyone fully tested FastMM for reliability under high-stress multithreaded DLL-based servers? Particularly where multi-core and HT is concerned?

  • Guest
    Kristofer Skaug Thursday, 29 September 2005

    Allen: 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?



    Pierre: 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.

  • Guest
    David Robb Thursday, 29 September 2005

    It amazes me that anyone could complain about the memory manager in either TP, BP or http://www.borland.com/delphi" target="_blank">Delphi.



    The 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!

  • Guest
    Robert Marquardt Thursday, 29 September 2005

    Complaining is our solemn duty! ;-)

    The http://www.borland.com/delphi" target="_blank">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.

  • Guest
    Zach Saw Monday, 03 October 2005

    "Borland's open RTL made it possible that memory managers such as FastMM could be written and plugged in with minimal effort."



    Correction:



    "Borland's open RTL made it possible that memory managers such as FastMM could be written and plugged into http://www.borland.com/delphi" target="_blank">Delphi with minimal effort."



    Try that with C++ Builder. Especially with Run-time packages.

  • Please login first in order for you to submit comments