Eric Pouech wrote:
Markus Amsler a écrit :
I've played around with dbghelp performance. My test case was breaking at an unknown symbol (break gaga) while WoW was loaded in the debugger (wine winedbg WoW.exe). The time was hand stopped, memory usage measured with ps -AF and looked at the RSS column.
Test Time(s) Memory Usage(MB) current git 4.5 54 pool_heap.patch 4.5 63 process_heap.patch 4.5 126 insert_first.patch 4.5 54 current git, r300 115 146 pool_heap.patch, r300 17 119 process_heap.patch, r300 17 260 insert_first.patch, r300 27 167
insert_first is the patch from Eric Pouech. r300 means with the debug version of Mesas r300_dri.so, which has a total compilation unit size of around 9.2M (compared to the second biggest Wines user32 with 1.1M).
Conclusions:
- current git wins with small debug files (<2M or so), pool_heap wins
with bigger files. insert_first, process_heap are out.
- small pools have less memory overhead than small heaps
- big pools have more memory overhead than big heaps.
- big pools are a lot slower than big heaps.
thanks for the testings & timings !
you're also missing a couple of elements:
- for the memory overhead, in the first case you consider 50 MB
(roughly) over 10 or 20 modules while in your r300 case the impact (and memory difference) is only on a single module
I'm not sure what's your point is.
- time to unload a module hasn't been computed (it's less used than
loading a module)
Unloading is more or less instant in all cases.
what's also strange is that the pool_heap gets lower memory consumption than the process heap one, which is rather not a natural result... I wonder if some data haven't been swapped out and aren't accounted for in RSS
The process_heap is the one I sent to wine-patches, which never frees any memory. I've also tested an improved process_heap, which stores the allocated memory pointer in an array and frees it afterwards. Without luck, it's slower and uses more memory the pool_heap.
So I don't see a simple solution which only affects storage.c, is equal or better than the current, and is significantly faster at big debug files. Any ideas?
Markus