|
Hey all,
I either need help getting VS to work correctly, or
am just bringing some hard data about the performance of a custom memory
allocator compared to the inbuilt one.
It was brought on by migrating from Delphi to
Visual Studio. Visual Studio appeared to be severely lacking in memory allocator
performance, even under release build configuration. Although I was unsure about
whether it was something I was doing or whether it was actually the case,
I ported across fastmm4 from Delphi. (I
haven't read the licenses to see if I can actually do that mind, but it's a
personal experiment) and noticed a huge performance increase.
Eg, standard interpreted Lua running
this:
"for i = 1,1024*1024*64 do local z = {}
end"
Takes just 9 seconds to create state, run and close
state under fastmm4, compared to 3 minutes 20
seconds of the default allocator. (20 times faster)
Furthermore the default allocator appears to have a large amount of overhead / fragmentation. Eg
this test: [[
local z, max = {},
1024*1024*32
for i = 1,max do z[i] = i % 16
end
for i = 1,max do z[i] = { z[i] }
end
for i = 1,max do
if (z[i][1]) ~= i % 16 then
error("mallocator is broken") end
end
]]
Takes 6.31GB of ram with the default allocator
(64 bit OS), and seems to hang (> 10 min) whilst trying to close
the state. (Presumably due to fragmentation, unsure. Without including the time
to close state, still takes over 100 seconds). Fastmm on the other hand takes
4.23GB and 26 seconds, including time taken to close the state. And that's with
16 byte aligning all allocs!
There has to be something wrong there
=S.
For anyone in the know I'm compiling
with:
"/Ox /Oi /Ot /Oy /I "C:\Users\Alex\Documents\Visual
Studio 2008\Projects\Lua\src" /D "_CRT_SECURE_NO_WARNINGS" /D "_UNICODE" /D
"UNICODE" /FD /EHsc /MD /Gy /Yu"stdafx.h" /Fp"x64\Release\Lua Standalone.pch"
/Fo"x64\Release\\" /Fd"x64\Release\vc90.pdb" /W3 /nologo /c /Zi /TP
/errorReport:prompt"
VS isn't performing memsets or anything is
it?
- Alex
|