Hi !
We have some performance problems with Wine that we could use some help on..
Here's the story:
We have been using TI code generation tools (compiler and linker) on Wine, and it has worked well. However, when we started evaluating newer versions of the codegen tools, the linking time was dramatically increased (from 20 sec to 30 minutes...).
We have done some profiling using oprofile, and found that most of this time (96%) is spent in the HEAP_FindFreeBlock* *function in the ntdll module. The time needed to locate a free heap block increases gradually, from a few iterations up to about 15000 in the project we are building. We suspect that this may be due to fragmentation caused by the heap allocate/free algorithms.
We do not have the same problem when building the code under Windows, so we tried to use the native ntdll.dll from Windows instead of ntdll.dll.so, hoping that this would solve the performance issue. We are aware that this is not recommended, but wanted to give it a try anyway. We added the dll file to the global dll-override section in the config file under ~/.wine/config, but it seems like Wine just looks for the builtin dll. We see from strace that we access the correct config file at startup. Is override of ntdll not supported, or have we missed something? If it is supported, is it likely that it is going to work?
We have read some posts in the newsgroup about the heap issues. It seems that people agree that the heap should be improved, either by tweaking the existing code, or by using another heap implementation. Is any work planned on this?
native ntdll.dll requires kernel system call hooks that WINE doesnt support . native ntdll.dll will never work on WINE.
Anders Rønningen wrote:
Hi !
We have some performance problems with Wine that we could use some help on..
Here's the story:
We have been using TI code generation tools (compiler and linker) on Wine, and it has worked well. However, when we started evaluating newer versions of the codegen tools, the linking time was dramatically increased (from 20 sec to 30 minutes...).
We have done some profiling using oprofile, and found that most of this time (96%) is spent in the HEAP_FindFreeBlock* *function in the ntdll module. The time needed to locate a free heap block increases gradually, from a few iterations up to about 15000 in the project we are building. We suspect that this may be due to fragmentation caused by the heap allocate/free algorithms.
We do not have the same problem when building the code under Windows, so we tried to use the native ntdll.dll from Windows instead of ntdll.dll.so, hoping that this would solve the performance issue. We are aware that this is not recommended, but wanted to give it a try anyway. We added the dll file to the global dll-override section in the config file under ~/.wine/config, but it seems like Wine just looks for the builtin dll. We see from strace that we access the correct config file at startup. Is override of ntdll not supported, or have we missed something? If it is supported, is it likely that it is going to work?
ntdll is one of the DLLs which will never be able to be used in Wine. So Wine ignores any dll-override line for it.
We have read some posts in the newsgroup about the heap issues. It seems that people agree that the heap should be improved, either by tweaking the existing code, or by using another heap implementation. Is any work planned on this?
Not that i know off. The Linux kernel VM is a good place to get ideas how to limit memory fragmentation.
bye michael
Hi !
We have some performance problems with Wine that we could use some help on..
Here's the story:
We have been using TI code generation tools (compiler and linker) on Wine, and it has worked well. However, when we started evaluating newer versions of the codegen tools, the linking time was dramatically increased (from 20 sec to 30 minutes...).
We have done some profiling using oprofile, and found that most of this time (96%) is spent in the HEAP_FindFreeBlock* *function in the ntdll module. The time needed to locate a free heap block increases gradually, from a few iterations up to about 15000 in the project we are building. We suspect that this may be due to fragmentation caused by the heap allocate/free algorithms.
Hi! Maybe this can also explain the slowdown of long-running apps under wine ? For example, DC++ runs perfectly when started, but after 12 hours of operation the window updates, search and other program functions are so incredibly slow, that it's better to kill it and restart. With regards, Pavel Troller
We have done some profiling using oprofile, and found that most of this time (96%) is spent in the HEAP_FindFreeBlock* *function in the ntdll module. The time needed to locate a free heap block increases gradually, from a few iterations up to about 15000 in the project we are building. We suspect that this may be due to fragmentation caused by the heap allocate/free algorithms.
Hi! Maybe this can also explain the slowdown of long-running apps under wine ? For example, DC++ runs perfectly when started, but after 12 hours of operation the window updates, search and other program functions are so incredibly slow, that it's better to kill it and restart. With regards, Pavel Troller
I don't know if that is specific to wine. The same happens to my edonkey on WinXP. Uses more and more memory and also handles until a restart is the better alternative.
bye Fabi
On Tue, 22 Feb 2005 12:52:33 +0100, Anders Rønningen wrote:
We have done some profiling using oprofile, and found that most of this time (96%) is spent in the HEAP_FindFreeBlock* *function in the ntdll module. The time needed to locate a free heap block increases gradually, from a few iterations up to about 15000 in the project we are building. We suspect that this may be due to fragmentation caused by the heap allocate/free algorithms.
That is quite possible. You can get a dump of the heap by doing a +heap trace, so there must be a function somewhere that generates it. Just trigger that when HeapFree gets too slow and see what it looks like.
You might (*might*) be able to get a feel for this by hacking the code to use glibcs malloc/free instead of our own heap implementation (but only when accessing the process heap). I do not know what might break if you do that. Doug Leas malloc may or may not be higher performance than ours.
thanks -mike
-
Anders Rønningen -
Fabian Cenedese -
Jonathan Wilson -
Michael Stefaniuc -
Mike Hearn -
Pavel Troller