your're right it was RtlAllocateHeap

Am 04.08.2013 11:25, schrieb Denis Shelomovskij:
04.08.2013 11:53, dennis luehring пОшет:
Am 04.08.2013 09:35, schrieb Walter Bright:
On 8/4/2013 12:19 AM, Joseph Rushton Wakeling wrote:
On Sunday, 4 August 2013 at 06:07:54 UTC, dennis luehring wrote:
ever tested nedmalloc
(http://www.nedprod.com/programs/portable/nedmalloc/) or
other malloc allocators?

"Windows 7, Linux 3.x, FreeBSD 8, Mac OS X 10.6 all contain
state-of-the-art
allocators and no third party allocator is likely to significantly
improve on
them in real world results."

So there may be minimal returns from incorporating nedmalloc on
modern OS's ... ?

As I wrote earlier, Microsoft has enormous incentive to make HeapXXXX
as fast as
possible, as it will pay dividends for every Microsoft software
product and
software designed for Windows. I'm sure the engineers there know all
about the
various strategies available on the intarnets. Why not take advantage
of their work?

HeapAlloc is a forwarder to RtlHeapAlloc and C++ new does call
RtlHeapAlloc directly - would it be better to use this kernel32 api
directly? (maybe if used in druntime to reduce dll dependencies)


Up to Windows XP (at least) KERNEL32's HeapAlloc function is forwarded
to RtlAllocateHeap [1] function exported by NTDLL so there is no runtime
performance overhead.

There is no RtlHeapAlloc function on my Windows XP and I can't find any
information about it on the web. Looks like a Windows 6.x stuff or a
mistake in name.

Also note there are tons of errors because of such "slightly different"
names. If we are talking about "Heap*" functions:
1. Incorrect "RtlAllocHeap" name here [2].
2. Incorrect "HeapFree" function signature (4-byte BOOL is returned but
it is just a wrapper of RtlFreeHeap which returns 1-byte BOOLEAN) (fixed
in Windows 6.x).

[1]
http://msdn.microsoft.com/en-us/library/windows/hardware/ff552108(v=vs.85).aspx
[2] http://msdn.microsoft.com/ru-ru/magazine/cc301808(en-us).aspx


Reply via email to