On Sun, 23 Jan 2005 10:18:55 -0800, Bryce Harrington wrote:
Yes, I'd love to hear your tips. The icon loading is something I've measured and know roughly how large of an impact it is, but if there are other things that can be done to speed it up, that'd be great to hear.
I'm hardly an expert, just an interested observer, but:
- Reducing the size of the codepath between main() and entering the main loop is important. Static linking GTKmm doesn't help here but as few apps use it the difference on most systems will be negligable (even an improvement as you optimize out the linker overhead). Lots of template usage can make code bigger too but there's not much we can do about that
- Putting anything that can be put off until the main loop goes idle for the first time is usually good
- Compiling for size not speed in some areas of the code may be useful (nail that all-important disk io!)
- Working set optimization is used *very* effectively at Microsoft, unfortunately we don't really have any good equivalent: Nats grope is probably the closest but it was designed to be a user tool. We need tools that let you profile and optimize the working set at compile time
- Constructing GUI can take a while, so it's best to delay loading/initialization of dialogs and palletes until they are needed
- Right now Inkscape and Inkview are *both* 7mb when I statically link GTKmm. Perhaps libinkscape should be turned into a dynamic library?
- Rearranging code in the source files can make a difference: strange but true. ld (I think) normally just concatenates the object files together. So by putting functions that are called together physically close in the source code, they're more likely to be in the same page on disk, reducing the number of page faults therefore reducing disk io
In case it's not obvious disk IO is *the* number one cause of startup time problems. Looking at the Inkscape startup code it's quite large, but then it's doing quite a lot of stuff (argument parsing, etc). I wonder if extensions could be loaded after the rest of the program?
I don't really see any obvious stuff though that could be removed from the startup path (which would make a difference).
thanks -mike