<HTML>
<div><style> BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; }</style>Apologies for my webmail client problems. There's little I can do about that.</div><div><br>
</div><div>This was the object pooling that I did - https://bugs.freepascal.org/view.php?id=34679 - though there's some cycle counting involved (e.g. in OptPass1MOV, only the integer registers are updated instead of all 8 types), this little bit of refactoring also fixed a couple of memory leaks as a side-effect, since two of the peephole optimisation routines created an array of TUsedRegs objects, but failed to free them afterwards. There are also quite a few locations where ReleaseUsedRegs is called multiple times in the same routine, mostly in an attempt to avoid using a "try...finally" block. Such configurations are just asking for a bug to be introduced where it's forgotten in one of the branches.<br>
</div><br>
Gareth aka. Kit<br>
<br>
<br>
<span style="font-weight: bold;">On Sat 15/12/18 19:37 , Martok listbox@martoks-place.de sent:<br>
</span><blockquote style="BORDER-LEFT: #F5F5F5 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">Sorry for hijacking the thread. Your mail client issue makes the conversation
<br>
really hard to follow, so I have literally no idea what the current subtopic of
<br>
a reply chain is, and there's little point in properly detaching a thread.
<br>
<br>
<br>
Am 15.12.2018 um 18:13 schrieb J. Gareth Moreton:
<br>
<span style="color: rgb(102, 102, 102);">> I dare ask, does that mean we should avoid workarounds in the compiler (and
</span><br>
<span style="color: rgb(102, 102, 102);">> our own programs) that aim to avoid constant construction and destruction of
</span><br>
<span style="color: rgb(102, 102, 102);">> objects, and instead try to improve the memory manager?
</span><br>
<br>
I was thinking more along the lines of avoiding cycle-counting special paths at
<br>
the cost of reliability, when there are much larger issues that would benefit
<br>
every program.
<br>
<br>
I would not be surprised if some of the large difference Simon listed when
<br>
calling out the bounty come from this side, instead of raw instruction throughput.
<br>
<br>
<br>
<span style="color: rgb(102, 102, 102);">> Thus, I would imagine that Delphi's *default* internal memory management
</span><br>
<span style="color: rgb(102, 102, 102);">> system is more along the lines of what is done in FPC's cmem unit, which is
</span><br>
<span style="color: rgb(102, 102, 102);">> well known to be objectively faster than FPC's default memory manager
</span><br>
I'm fairly certain the runtime is written in Pascal, except for parts of the
<br>
startup code. The memory manager at some point (I think D2006?) adopted FastMM:
<br>
<<a target="_blank" href="<a href="http://docwiki.embarcadero.com/RADStudio/2010/en/Configuring_the_Memory_Manager%26gt">http://docwiki.embarcadero.com/RADStudio/2010/en/Configuring_the_Memory_Manager%26gt</a>"><span style="color: red;">http://docwiki.embarcadero.com/RADStudio/2010/en/Configuring_the_Memory_Manager></span></a>;
<br>
In any case, FPC's cmem on Win32 calls into mscvrt, and that is so slow that I
<br>
killed the test code after a couple of minutes, where even FPC-builtin was done
<br>
after 10 seconds.
<br>
<br>
<br>
<br>
--
<br>
Regards,
<br>
Martok
<br>
<br>
<br>
_______________________________________________
<br>
fpc-devel maillist - <a href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a>
<br>
<a target="_blank" href="<a href="http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</a>"><span style="color: red;">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</span></a>
<br>
<br>
<br>
</blockquote></HTML>