Re: Lua and custom memory allocators

["Ivo Beltchev" <ivo@...>]

Try running the application without the debugger attached (Ctrl+F5 instead of F5). I noticed that if the debugger is present the OS uses a slower version of the heap. The difference is noticeable on XP, but is significant on Vista. If you run without a debugger and then attach, all is well.

Ivo

----- Original Message ----- 
From: "Mike Pall" <mikelu-0804@mike.de>
To: "Lua list" <lua@bazar2.conectiva.com.br>
Sent: Wednesday, April 30, 2008 8:57 AM
Subject: Re: Lua and custom memory allocators


> Alex Davies wrote:
> > I'm lost as to why my VS seems to be so slow.
> 
> It's not about the VS version or the compiler you use. The culprit
> is the C runtime library you are linking against (not that you
> have much of a choice with a given VS version).
> 
> MSVCR70 and later (in release mode) just hand all calls to malloc
> over to HeapAlloc. Older versions up to and including MSVCRT6
> supposedly do some internal pooling for small memory allocations.
> 
> This means you are probably experiencing the (lack of) performance
> of HeapAlloc, which is OS-specific. From a quick search on the web
> it seems that this has varied from plain awful (pre-W2K) to so-so
> (Vista). For this reason practically every larger Windows app
> includes their own malloc replacement. Seems you've just
> discovered this yourself. :-)
> 
> About GNU toolchains for Windows: MinGW32 links against MSVCRT6,
> MinGW64 links against MSVCR80 and Cygwin links against a port of
> glibc by default. Again, this has nothing to do with the compiler,
> which is GCC in all cases.
> 
> --Mike
>