bszente: no, you're not the only one to experience the problem, and I'm concerned about it.
Here's an extract of a PM I sent to Yiannis:
*
Performance issues:
I have spent some time trying to find a profiler other than gprof (because it's known limitations).
I couldn't find any free win32 one (I use CodeAnalyst from AMD which is really good but only works with VC on win32, and for linux it works with gcc but requieres kernel recompilation).
I became very concerned about the hotspot:
-C::B initial load is very slow (it is more than Firefox :shock:). On first load it takes 15 seconds on this machine, and 5 seconds on subsequents loads.
That is crossing the barrier between acceptable, but it's still not much.
The problem relies when I need to use C::B at univ., because the programs can only be loaded from the lan. It takes
50 seconds :shock: to load, while almost any other program takes less (SciTE takes 1 seconds).
At first I thought that it was the lexers, but they are part responsible only. The lexers usually take a constant time of 4 seconds on every load (that is, when running C::B or opening the Editor dialog).
About that, couldn't the lexers be loaded only on C::B load instead of on every Editor dialog aperture (cached)?
But after all I noticed probably most time is spent in stub dll loading, almost 0.8~2 seconds for each plugin dll, which when added to lexers, I reach the 15 seconds that C::B tooks on first load (on my pc: Athlon 64 3000, 512MB).
I don't know other way to solve that unleast using the GCC4 feature visibility=hidden. See here:
http://gcc.gnu.org/wiki/Visibility
