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? So many discoveries! Gareth aka. Kit P.S. This thread is supposed to be for the x86_64 optimizer overhaul that I presented!
On Sat 15/12/18 18:01 , Martok list...@martoks-place.de sent: Am 15.12.2018 um 17:12 schrieb Florian Klämpfl: > The memory manager itself pools already, so no need for the compiler. If somebody wants to improve the heap manager: > implement OS supported re-allocations (OS can move memory by just shuffling pages). Very much agree, it's not a user program's job to work around the standard memory manager in daily use. Doing that is a C++-ism that shouldn't exist in a sane environment ;-) I just tested something, and I'm a surprised by how big the difference is. This simple test is 1.5 times slower in FPC/trunk/win32 than Delphi 2007 and 2.8 times slower for instances of TComponent. Medium-size GetMemory (I tested 123 bytes) is 22 times slower in FPC. Looks like there is quite some potential there. const COUNT=10000; var t1, t2: dword; objs: array[0..10000] of TObject; i, j: integer; begin t1:= Gettickcount; for i := 0 to COUNT - 1 do begin for j := 0 to high(objs) do objs[j]:= TObject.Create; for j := 0 to high(objs) do objs[j].Free; end; t2:= Gettickcount; writeln((t2-t1)/COUNT:10:3, 'ms'); Readln; end. -- Regards, Martok _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org [1] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel [2]">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel Links: ------ [1] mailto:fpc-devel@lists.freepascal.org [2] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
