perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Jacobowitz <d...@andrew.cmu.edu>
Subject Re: perlrequire/perlmodule are running twice and slow
Date Sun, 25 Nov 2001 16:42:53 GMT
On Mon, Nov 26, 2001 at 12:10:00AM +0800, Stas Bekman wrote:
> Great to know that you are going to work this out. But what are you 
> planning to work on to improve the situation?

I'm not precisely sure.  There is an easy solution which assumes that
you aren't setting breakpoints in the modules until after they're
loaded - just keep going until we stop for something OTHER than a
shared library event.  But, if you're debugging libperl.so, that won't
help much.

> 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.

Is it possible that Doug and Philip do not have libthread_db installed,
in which case GDB won't try to be thread-aware?  Or, actually, it could
be a gdb version issue.  The slowness came with the current
thread-aware debugging package, which is fairly recent (snapshots from
a year ago through the release last week).

In this case, there are two things to do; clean up the generic shared
library code and clean up the threads code.  The latter is much more
urgent and much more likely to be useful.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message