<div dir="ltr"><div dir="ltr">On Sat, Dec 15, 2018 at 2:37 PM Martok <<a href="mailto:listbox@martoks-place.de">listbox@martoks-place.de</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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></blockquote><div><br></div><div>Interesting. On Win64 I've found it to be consistently faster. Also, the cmem unit changed to call into a copy of Jemalloc.dll (i.e. je_malloc instead of malloc and such), something I've experimented with, is WAY faster.</div><div><br></div><div><div dir="ltr">On Sat, Dec 15, 2018 at 2:43 PM Jonas Maebe <<a href="mailto:jonas@freepascal.org">jonas@freepascal.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">That is incorrect.</blockquote><div><br></div><div>I didn't mean that it doesn't *care* about being fast, but more that it will not necessarily use more memory in all cases that it might result in a speed gain, and generally is more concerned with a "balanced" approach, which is what I've always heard to be the case. Is that really not true at all?</div></div></div></div></div>