[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Lua and custom memory allocators
- From: "Ivo Beltchev" <ivo@...>
- Date: Wed, 30 Apr 2008 09:11:48 -0700
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.
----- Original Message -----
From: "Mike Pall" <firstname.lastname@example.org>
To: "Lua list" <email@example.com>
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.