"Boaz Harrosh" boaz@hishome.net wrote:
[...] so I'm curious where all of the time is spent.
Most definitely the Linux-shared loader. It took ages. The code is heavy C++ code full of templates with weak symbols, inline virtual functions, and plain horizontal code structure. almost any thing you can do to slow a linker down.
Ah, ok. Our code isn't too heavy with templates. For a while, we only used a few container classes here and there, but recently we have been using more and more templates, particluarly with stl and boost.
The PE export-import tables are much better in this situation since there is no searching to do. (and no fixups) All searching if any is done in link-time.
Did you happen to try making all of the symbols in all of your shared libraries resolve through wine via .spec files? I'm curious how the speed would compare. I assume that the speed gained from the more efficient lookups would be lost by some extra work wine has to do. For us, it wouldn't matter much because the majority of our libraries are completely native.
Speaking of which I was never able to statically link the winlib app on Linux. I put up a machine with 2-Gg of ram + setup 2Gg of swap space. The linker would work for 5-10 minutes than it would hit the swap space. Memory would go up and up until about 50 minutes where the kernel starts to kill every thing in sight including the Linker.
Wow. That was something I wanted to try at some point, but our startup time hasn't yet been bad enough for us to want go to a static app.
Please do post your results on how to Link the .so on the winegcc command line.
I will. Hopefully we'll be trying that this week.
And also most important if you succeed with prelinking. I think that is the best way to go but I'm not a Linux guru and didn't manage to do it.
I'll let the list know how that turns out when we get around to it (which *might* be this year, might not...).
Thanks for sharing your experiences.
Eric