Sorry for hijacking the thread. Your mail client issue makes the conversation really hard to follow, so I have literally no idea what the current subtopic of a reply chain is, and there's little point in properly detaching a thread.
Am 15.12.2018 um 18:13 schrieb J. Gareth Moreton: > I dare ask, does that mean we should avoid workarounds in the compiler (and > our own programs) that aim to avoid constant construction and destruction of > objects, and instead try to improve the memory manager? I was thinking more along the lines of avoiding cycle-counting special paths at the cost of reliability, when there are much larger issues that would benefit every program. I would not be surprised if some of the large difference Simon listed when calling out the bounty come from this side, instead of raw instruction throughput. > Thus, I would imagine that Delphi's *default* internal memory management > system is more along the lines of what is done in FPC's cmem unit, which is > well known to be objectively faster than FPC's default memory manager I'm fairly certain the runtime is written in Pascal, except for parts of the startup code. The memory manager at some point (I think D2006?) adopted FastMM: <http://docwiki.embarcadero.com/RADStudio/2010/en/Configuring_the_Memory_Manager> In any case, FPC's cmem on Win32 calls into mscvrt, and that is so slow that I killed the test code after a couple of minutes, where even FPC-builtin was done after 10 seconds. -- Regards, Martok _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
