brian.lu wrote:
> Hi, experts,
> 
> I have a question. When studying firefox startup performance, I found 
> that ld.so.1 spent more than 1 second  to load some shared library. This 
> libraries is loaded by dlopen().
> How can I know what's the most time consuming operation in this loading?

The first thing I'd do would be to isolate the dlopen().  Create a dummy
program:

        % cat > main.c
        #include <dlfcn.h>
        
        void main()
        {
                dlopen("slow-app", RTLD_LAZY);
        }

And then use LD_DEBUG= to get an idea of what's going on.   I've
used RTLD_LAZY here, but you should use whatever firefox is using.

LD_DEBUG=files to see what dependencies are loaded.
LD_DEBUG=symbols,detail to see all symbol lookup
LD_DEBUG=reloc,detail to see all relocations

You can then drill deeper.

The attached dtrace script is one I use to get a general overview.
I'll add or subtract from this to get more info.  The output is
something like:

% dtrace -x evaltime=exec -32 -qC -c ./firefox-bin -s  ~/dtrace/all.d

Call Counts:
                 memcpy:          3125
                 strlen:          3244
                 malloc:          3333
               elf_bndr:          3726
             elf_rtbndr:          3726
        load_completion:          3830
     elf_reloc_relative:         10566
               elf_hash:         20062
                 strcmp:         86359
           elf_find_sym:        381467

Raw Times (msecs):
        load_completion:        742774
              call_init:        747819
              file_open:        970683
              elf_reloc:       1214110
            relocate_so:       1214372
                load_so:       1278085
               load_one:       1286340
              load_path:       1287142
           elf_find_sym:       1338652
           relocate_lmc:       1581881


relocate_lmc() is the main relocation engine, which
spends most of its time looking up symbols (elf_find_sym()).

Note the "call_init" too.  This is where ld.so.1 calls the
.init sections of any loaded objects.  I've seem dlopen()
objects that do huge amounts of .init processing - this
all occurs before return from the dlopen().  .init's have
been known to dlopen() other objects, start threads, and
even fork/exec programs :-)

I'm sure a much better DTrace script could be written.

Which object are you observing that takes so long to dlopen()?

-- 
Rod
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: all.d
URL: 
<http://mail.opensolaris.org/pipermail/tools-linking/attachments/20051124/f08865ca/attachment.ksh>

Reply via email to