site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Sep 24, 2006, at 11:06 PM, Sudarshan S wrote: I am trying to understand loading sequence when an application is executed. I found that TextEdit.app opens more than 100 files whenever it is executed. Most of these files are plist, dylib and some dependent files in Frameworks. This was observed through Kauth hook. I would like to know whether these files are opened in sequence,i.e one at a time or not. If dependent files are opened in sequence, is that the reason why heavy applications like Firefox takes longer time to execute ? - - -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... Yes, opening these files is a seriailization point, since there is only a single thread running at the time. Generally, no. As a percentage of time, that's not where you are burning your seconds, which you'd likely see if you'd profiled the code. More likely, it's the static initialization that's done at load time for C++ objects, instead of at link time (predone) or runtime (as needed). A very simple test that would demonstrate this is having a pre-heated cache, and seeing how much launch time differs (i.e. start it once to load the browser cache, reboot, start it again to preheat the file cache, exit it, quit out completely, waiting for the system to quiesce, and start two more times, and see what the difference is in time -- the first load and reboot is necessary to separate buffer cache effects and browser cache effects). The problem with initializers is that the C++ standard does not specify an order for calling them. The typical order on g++ based C++ compilers is in the order that the modules were linked, rather than the dependency order for the objects, based on their inheritance relationships. As a result, you will tend to see some thing sthat work well on compilers that deal with hierarchical runtime initialization (e.g. SunSoft C++, Oregon C++, IBM's xLC++, etc.) or compile time initialization (MSVC++, Borland C++, etc.) that tend to fail miserably with runtime initialization when compiled with g++-based compilers that don't fire their initializers at load time (because of link-time decisions). As an example, when Jeremy Allison and I got Qualcomm's ACAP reference implementation running under g++ 2.95 (we had to deal with implementing per-thread exceptions into libg++ to support this), when object files were linked in reverse dependency order, everything just worked, but when they were linked in the default order that came with the ACAP Makefile reference implementation, things would crash due to partially constructed static objects being used. Typically, you can significantly reduce the static initializer overhead by using a "singleton" pattern, and performing initialization of objects at runtime, rather than providing static initializers (i.e. global declarations end up as pointers to class objects/structures, rather than as instances). I don't know how far down that road, you'd want to go with the Firefox sources, of course, but if you climb that mountain, you should see start time performance wins on other platforms as well (e.g. FreeBSD, Linux, etc.), at the same time avoiding what must be carefully constructed ordering of object file names in Makefile's, which is probably fragile enough that developers stub their toes on it pretty frequently. FWIW: It'd probably be more worthwhile in the long run for someone to address supporting communicating hierarchical initialization relationships between the compiler and the linker, and either put the preinitialized objects in the BSS, or make it so runtime linking in g+ + wasn't dependent on link order. This email sent to site_archiver@lists.apple.com