Re: File opens while executing an application
Re: File opens while executing an application
- Subject: Re: File opens while executing an application
- From: Terry Lambert <email@hidden>
- Date: Mon, 25 Sep 2006 14:09:39 -0700
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.
Yes, opening these files is a seriailization point, since there is
only a single thread running at the time.
If dependent files are opened in sequence, is that the
reason why heavy applications like Firefox takes
longer time to execute ?
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.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden