Ah right, so things like "TmpUsedRegs" (an array of TUsedRegs) constantly being created and destroyed in the peephole optimizer is actually not that much of a penalty hit, and creating a pooled object for continuous use doesn't give that much of a performance gain?
Gareth On Sat 15/12/18 16:12 , Florian Klämpfl flor...@freepascal.org sent: Am 12.12.2018 um 13:49 schrieb Ryan Joseph: > > >> On Dec 12, 2018, at 7:20 PM, Martok wrote: >> >> Checking out the memory manager(s) could be useful as well - there are a lot of >> small allocations, that generally tends to put much stress on it. >> And any improvement there would also directly benefit user applications. > > I was going to say the same thing myself and even planned to do a test. My profiles show the top hits being getmem/freemem which really don’t need to be there. > > There’s no reason to be allocating and freeing nodes (for example) over and over again when we could just allocate a large pool at startup and return to the pool instead of freeing. It would make the compiler utilize more memory but that’s a good trade off for me personally. This is especially a good idea because the compiler is a one pass program so leaks over the long term aren’t a problem. 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). _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org [2] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel [3]">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel Links: ------ [1] mailto:list...@martoks-place.de [2] mailto:fpc-devel@lists.freepascal.org [3] 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
