5 Jan
2005
5 Jan
'05
12:08 a.m.
Alex Ionescu wrote:
By the way, I've made some serious performance
improvements to the
code, by adding a static buffer which is used to hold up to 64 debug
sections. The rest are then allocated by using the heap. This has a
two fold advantage:
1) The first CS (used by the Heap Manager on ROS, probably on WINE
too), one for RtlInitializeHeapManager and the other for
RtlAllocateHeap now also have a valid Debug Section, because they use
the static one.
2) Because the kernel-call is removed, it offers significant
improvments on ROS, on WINE too, since there is less code that must
run (a tiny loop versus a whole heap allocation).
A call to RtlAllocateHeap doesn't normally result in a kernel-call.
I'm thinking about sending a patch to WineDevel...
since it's only two
functions to be added and the brute heap calls to be replaced by the
function names, I think it would be easy to integrate.
For most process-wide critical sections we don't allocate a DebugInfo
anyway; we just store the critical section and the DebugInfo structure
in the .data section of the DLL and don't call
RtlInitializeCriticalSectionAndSpinCount. So, I don't think it would be
that much of a performance improvement for Wine. Anyway, if you wanted
the performance, you should just disable the code that allocates the
DebugInfo, like release versions of Windows do.
However, patches to manipulate the EntryCount and ContentionCount
members would be welcome as they could be useful in identifying
performance bottlenecks.
Rob