5 Jan
2005
5 Jan
'05
1:06 a.m.
Robert Shearman wrote:
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.
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. 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