views:

32

answers:

1

I am now trying to optimize the launch time of an application, and currently want to reduce the time spent by the OS image loader.

From dyld(1), I found two environment variables: DYLD_PRINT_STATISTICS and DYLD_PRINT_INITIALIZERS.

DYLD_PRINT_STATISTICS causes dyld to print statistics about how dyld spent its time. This is its output when I launched the application after a purge command.

total time: 5.9 seconds (100.0%)
total images loaded:  130 (101 from dyld shared cache, 0 needed no fixups)
total segments mapped: 105, into 12914 pages with 840 pages pre-fetched
total images loading time: 1.8 seconds (31.0%)
total dtrace DOF registration time: 0.09 milliseconds (0.0%)
total rebase fixups:  137,658
total rebase fixups time: 1.1 seconds (19.4%)
total binding fixups: 28,502
total binding symbol lookups: 1,127, average images searched per symbol: 0.1
total binding fixups time: 452.28 milliseconds (7.6%)
total weak binding fixups time: 188.52 milliseconds (3.1%)
total bindings lazily fixed up: 130 of 1,164
total initializer time: 2.3 seconds (38.7%)
total symbol trie searches:    2611
total symbol table binary searches:    118
total images defining/using weak symbols:  13/65

Apparently, calling initializer functions use lots of time. So I tried DYLD_PRINT_INITIALIZERS to get the list of initializer functions.

I actually got them, but there was no time information on them, such as a timestamp, just tons of following lines:

dyld: calling initializer function 0x25170 in MY_APPLICATE_PATH

This is useless for me to find the target initializers to optimize.

So, my questions are:

  1. Is there any method to make dyld print timestamps?
  2. If it is impossible, could I use something else to profile the time of calling initializer functions by dyld? Is DTrace or Instruments applicable here?
  3. Any advices on the above statistics are appreciated.

Although I am now working on OSX, any tools or helpful information for Windows are also welcome.

Thanks

+1  A: 

Can you use this technique?

I've seen slow startup of a large app, which was loading a lot of dlls and doing a lot of initializing. Sampling will tell what's going on, that you can fix, and it will probably surprise you.

For example, what I never would have guessed is the amount of time spent setting up internationalized character strings, many of which did not need to be. Another example: not only creating and initializing data structures, but destruction and re-creation of them, needlessly, as things were being inserted in menus, tree views, etc.

Mike Dunlavey