Robert Shearman wrote:
Alex Ionescu wrote:
A call to RtlAllocateHeap doesn't normally result in a kernel-call.
Even without them, heap code is much much slower, then allocating a static buffer, because of all the searches and control that must be done.
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.
Yes, unfortunately shell32.dll calls RtlDeleteCriticalSection in changenotify.c and iconcache.c. I had to remove those calls from the ROS tree because the code will think the Debug Data is in a heap and try to free it, which raises a warning. I think it's wrong to call them on wine too, even if no errors happen, because you shouldn't delete sections you statically allocate in your dll .data section.
So, I don't think it would be that much of a performance improvement for Wine.
Probabaly minimal, yes, for now.
Anyway, if you wanted the performance, you should just disable the code that allocates the DebugInfo, like release versions of Windows do.
People keep telling me this, but I have not been able to reproduce this behaviour on my retail machines. Perhaps this was in NT4?
However, patches to manipulate the EntryCount and ContentionCount members would be welcome as they could be useful in identifying performance bottlenecks.
Once my code becomes more stable and stack backtrace gets added, I will send everythign to wine, also in hope that they will get rid of the static CS and use dynamic ones...its' much cleaner, imo.
Rob
Best regards, Alex Ionescu