Daniel Jacobowitz wrote:
> On Thu, Nov 22, 2001 at 09:49:47AM +0800, Stas Bekman wrote:
>
>>Doug MacEachern wrote:
>>
>>
>>>On Thu, 22 Nov 2001, Stas Bekman wrote:
>>>
>>>
>>>
>>>>As part of trying to figure out why my t/TEST -d takes so long to start,
>>>>I've traced that it spends about 14 secs in modperl_extra.pl. Can you
>>>>reproduce the same?
>>>>
>>>>
>>>it does take quite a bit of time to parse all the perl code that is loaded
>>>and for gdb to build symbols tables from all the shared libraries. 14
>>>seconds seems too long though.
>>>
>>
>>is there way to preload things and keep them in memory? since I don't
>>
>>change any of the perl stuff when I play with gdb. I've tried to preload
>>
>>libmodperl.so and libperl symbols in gdb, but I couldn't make it work,
>>
>>since I've to tell it the address space to load it too. Not sure how to do
>>that.
>>
>
> Not really. It's not symbol loading that's taking all your time. GDB
> behaves very badly when loading any large number of shared modules; I'm
> trying to sort that code out this month anyway. It's trying to parse
> _DYNAMIC (the link map) at every shared library event. It's a
> difficult problem; if we don't do this, then we can't reset breakpoints
> in shared modules as they are loaded.
Great to know that you are going to work this out. But what are you
planning to work on to improve the situation?
We do load a *lot* of shared objects:
/home/stas/apache.org/modperl-2.0> find . | grep so | wc -l
42
Not sure if we try to load all of them during 'make test', but quite a
few of these for sure.
> Just be glad you aren't linked to -lpthread. Then it REALLY takes
> forever.
It is linked with pthread :(
% ldd /home/stas/httpd/threaded/bin/httpd
libaprutil.so.0 => /home/stas/httpd/threaded/lib/libaprutil.so.0 (0x40017000)
libapr.so.0 => /home/stas/httpd/threaded/lib/libapr.so.0 (0x40026000)
libdb.so.2 => /usr/lib/libdb.so.2 (0x40057000)
libm.so.6 => /lib/libm.so.6 (0x40065000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x40088000)
libnsl.so.1 => /lib/libnsl.so.1 (0x400b7000)
libdl.so.2 => /lib/libdl.so.2 (0x400cd000)
libssl.so.0 => /usr/lib/libssl.so.0 (0x400d1000)
libcrypto.so.0 => /usr/lib/libcrypto.so.0 (0x400fe000)
libexpat.so.0 => /home/stas/httpd/threaded/lib/libexpat.so.0 (0x401c0000)
libpthread.so.0 => /lib/libpthread.so.0 (0x401de000)
libc.so.6 => /lib/libc.so.6 (0x401f6000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
The thing that drives me crazy is that neither Doug nor Philip who both
use almost the same version of everything on linux and using the same
build options don't have this huge startup lag. I cannot figure out what
it is that is different on my system that only I see this problem :( Any
hints? I was trying to profile the startup to figure out where gdb
spends most of the time but first I couldn't get any DSO loaded gprof
data second I'm not sure I can really catch it. Should I use kernel
level tracing? strace doesn't reveal anything interesting, it shows the
PTRACE_PEEKTEXT op all the time, but nothing else I can use to aid my
tracing.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
