Of course, I couldn’t have been done with simply improving the startup times of xine-based applications by hiding all the extraneous symbols by replacing the old minsymtab hack that didn’t work that well with GNU ld.
After fixing all the xine plugins to use -fvisibility=hidden to hide all the symbols but the ones needed, I decided to go a step further and look for other possible optimisations.
The first is not something that really helps me out, as I don’t use xvmc/xxmc, but for who is using them, and using nvidia-glx, at least on Gentoo, this might help:
ln -s libXvMCNVIDIA.so.1.0.$driver_version /usr/lib/libXvMCNVIDIA.so
where $driver_version is the version of the nvidia drivers you’re using (in my case it’s 8756). This allow xine to find libXvMCNVIDIA.so when using -lXvMCNVIDIA and thus using the shared version of the it, reducing the size and the number of symbols of xvmc/xxmc output plugins.
It has to be said that reducing the number of plugins built/loaded is really a good idea, as it will take way less time to load them if you skip the ones you don’t use at all. Although I’ve hidden all the symbols from the plugins and then they don’t need to be relocated, things like opengl output plugin require to bind the whole libGL.so, and that takes quite a lot of time. For this reason I’m going, in the 1.2 cvs rev of xine-lib-1.1.2_pre20060328-r4, to enforce usage of v4l useflag so that it won’t build v4l/pvr plugins is not requested.
But not even this is enough for me 🙂 I still had in mind a post from Ben Maurer (from the GNOME team, mind you, don’t try to tell that I’m a KDE-only guy 😉 ) which talked about shared memory usage. Following that post I actually created a patch for fontconfig that’s now (mostly) merged upstream – mostly because one of the change is no more pertinent as the way to handle the struct has changed – that reduced the private memory usage of a little bit.
Anyway, with that in mind, I’ve started looking for things to mark constant in xine-lib, as looking at the smem.pl output for amaroK shown the majority of plugins having private mappings. The first obvious thing was to mark constant the one symbol they export, xine_plugin_info, that’s an array of structures. That really helped, now instead of being exported in the .data section, it’s exproted in .data.rel.ro and most of the plugins before in private mappings are in shared ones. Good!
But that’s not even enough, there are more “blobs” that should be marked const to avoid private/dirty mappings, and I’m now working on this. Hopefully this will help improving performance and memory usage of xine, amaroK and Kaffeine themselves. Good thing for me. Actually, I can already see amaroK and Kaffeine starting in less time since I’m hiding symbols in plugins, and also amaroK takes less time changing song.
Of course I’m doing this on my free time, so you can always thanks me if you feel like so 😉
No, actually I’m doing this mainly because I find it interesting and I want to improve my system and the experience users have of xine. Since I started handling it last year I’ve done as much as I could so that it worked out of the box and at the best of its capabilities, I hope I was able to do so, I actually find it working better than it was before and even more of when I was on Debian. This of course is mostly because of the good developer upstream, but in a little part I hope to have contributed to it.
Anyway, I’m returning to compiling/checking memory usage 🙂
