Re: To Discuss: Application Startup Time

[Alexander Larsson <alexl redhat com>]

On Wed, 2004-03-03 at 14:03, Soeren Sandmann wrote:
> Havoc Pennington <hp redhat com> writes:

> 
> I have a profiler that presents basically the same data as speedprof,
> but for the entire system, not just a single application. It's
> unfinished and crude, but it does basically work:
> 
>         http://www.daimi.au.dk/~sandmann/sysprof-0.02.tar.gz
> 
> It uses a kernel module, so you'll need to have kernel source
> available to build it, and you need to be root to install the kernel
> module. Also, for some reason the profiler itself has to run as root
> to get symbols from the X server.
> 
> Dynamic linking is one thing that has been studied. I don't know much
> about it, but I'll note that Mike Hearn pointed out that on Windows a
> shared library is quite often really a COM component. As I understand
> it such a component doesn't offer a big set of function entry points
> like the typical Linux library; instead it offers only one, the
> "QueryInterface" function. Calling that function returns a pointer to
> a vtable, where all the real functions are. I imagine having only one
> public function in the library reduces linking time significantly.
> 
> But to get startup times closer to the MS Office range, disk use is
> probably even more important than CPU use. The problem is that there
> aren't any disk profilers that I know of. Off the top of my head, here
> are some things that would be nice to measure:

Another thing that windows does better is pure code-size as generated by
gcc vs the MS compiler. Check out, from
http://bugzilla.mozilla.org/show_bug.cgi?id=231995 :


------- Additional Comment #9 From Alec Flett 2004-02-04 06:37 PST  [reply] ------- 
I find it rather fascinating that there is such a difference between the linux
reduction and the windows reduction - Is there something else at play here? Are
we eliminating unused methods that the windows linker was already culling out? 

------- Additional Comment #10 From Darin Fisher 2004-02-04 09:08 PST  [reply] ------- 
well, there are several things at play for sure...

1) NS_COM is still being applied to some of the string classes (like nsString),
and that causes a lot of inline symbols to be exported.  this problem doesn't
exist under linux, so this might explain why the savings in xpcom is not as good
under MSVC.

2) more importantly though, MSVC just generates better code.  take a look at
codesize totals for example: linux seamonkey went from 21148 to 20196, and win32
seamonkey went from 13101 to 12821.  so, that's a 4.5% savings on linux and a
2.1% savings on win32.  in other words, though it appears that we are saving 3-4
times as much on linux, percentage wise the savings is actually just double.

3) remember that business about MSVC not being penalized by early returns as
much as GCC?  (i.e., GCC doesn't coalesce multiple return statements very well,
resulting in a lot of duplicated destructor code.)  i think that might be having
an affect here since it takes less code to call a DSO method than it does to
call a virtual method.  recall: i've made all methods on nsAString non-virtual.

that said, i definitely plan to spend some time looking at the MSVC generated
assembly to see if we are doing something that causes obvious problems for MSVC.



Of course, this is C++, and most of our code is C, but still. The gcc
generated code above is almost twice the size of the MSVC one.


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a scrappy soccer-playing grifter who must take medication to keep him 
sane. She's a bloodthirsty African-American widow with a flame-thrower. They 
fight crime!