You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Stas Bekman <st...@stason.org> on 2001/11/21 17:56:51 UTC
perlrequire/perlmodule are running twice and slow
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?
here is the modified t/conf/modper_startup.pl (I know it's autogenerated)
BEGIN {
my $file = "/tmp/out";
open my $fh, ">>$file" or die $!;
select $fh;
use lib '/home/stas/apache.org/mp-subproc/t';
for my $file (qw(modperl_inc.pl modperl_extra.pl)) {
print "start: ".scalar(localtime)."\n";
print "require $file\n";
eval { require "conf/$file" } or
die if grep { -e "$_/conf/$file" } @INC;
print "end: ".scalar(localtime)."\n";
}
close $fh;
}
1;
I get:
start: Wed Nov 21 23:53:00 2001
require modperl_inc.pl
end: Wed Nov 21 23:53:00 2001
start: Wed Nov 21 23:53:00 2001
require modperl_extra.pl
end: Wed Nov 21 23:53:13 2001
start: Wed Nov 21 23:53:13 2001
require modperl_inc.pl
end: Wed Nov 21 23:53:13 2001
start: Wed Nov 21 23:53:13 2001
require modperl_extra.pl
end: Wed Nov 21 23:53:14 2001
Also this shows that BEGIN block of startup.pl is running twice. I don't
think this is right. (BTW, people are still reporting this problem with
mod_perl 1.26!)
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: perlrequire/perlmodule are running twice and slow
Posted by Daniel Jacobowitz <dm...@andrew.cmu.edu>.
On Tue, Nov 27, 2001 at 09:27:18AM +0800, Stas Bekman wrote:
> Daniel Jacobowitz wrote:
>
> >On Tue, Nov 27, 2001 at 02:02:57AM +0800, Stas Bekman wrote:
> >
> >>I've a bunch of them, but I think that the one in /lib/ that's used:
> >>
> >>% urpmf libthread_db
> >>glibc:/lib/libthread_db-1.0.so
> >>glibc:/lib/libthread_db.so.1
> >>glibc_lsb:/lib/lsb/libthread_db-1.0.so
> >>glibc_lsb:/lib/lsb/libthread_db.so.1
> >>glibc-devel:/usr/lib/libthread_db.so
> >>glibc_lsb-devel:/usr/lib/lsb/libthread_db.so
> >>
> >>what should I ldd to figure out which one is used?
> >>
> >
> >Well, what version of the glibc RPM is installed? (glibc, not any of
> >the others). My bet is that his is just broken somehow; I recall a
> >recent version having that problem.
>
>
> His is broken, but it works nicely with gdb? I want my to be broken that
> way too! :)
His is probably broken to just turn off thread debugging somehow :P
> Mine are (Mandrake cooker):
>
> glibc-2.2.4-11mdk
> glibc-profile-2.2.4-11mdk
> glibc-devel-2.2.4-11mdk
>
>
> Philippe's are (RH 8.1):
>
> glibc-devel-2.2.4-19
> glibc-2.2.4-19
> glibc-profile-2.2.4-19
I admit to having no idea what's going on, then.
--
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
Re: perlrequire/perlmodule are running twice and slow
Posted by Stas Bekman <st...@stason.org>.
Daniel Jacobowitz wrote:
> On Tue, Nov 27, 2001 at 02:02:57AM +0800, Stas Bekman wrote:
>
>>I've a bunch of them, but I think that the one in /lib/ that's used:
>>
>>% urpmf libthread_db
>>glibc:/lib/libthread_db-1.0.so
>>glibc:/lib/libthread_db.so.1
>>glibc_lsb:/lib/lsb/libthread_db-1.0.so
>>glibc_lsb:/lib/lsb/libthread_db.so.1
>>glibc-devel:/usr/lib/libthread_db.so
>>glibc_lsb-devel:/usr/lib/lsb/libthread_db.so
>>
>>what should I ldd to figure out which one is used?
>>
>
> Well, what version of the glibc RPM is installed? (glibc, not any of
> the others). My bet is that his is just broken somehow; I recall a
> recent version having that problem.
His is broken, but it works nicely with gdb? I want my to be broken that
way too! :)
Mine are (Mandrake cooker):
glibc-2.2.4-11mdk
glibc-profile-2.2.4-11mdk
glibc-devel-2.2.4-11mdk
Philippe's are (RH 8.1):
glibc-devel-2.2.4-19
glibc-2.2.4-19
glibc-profile-2.2.4-19
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: perlrequire/perlmodule are running twice and slow
Posted by Daniel Jacobowitz <dm...@andrew.cmu.edu>.
On Tue, Nov 27, 2001 at 02:02:57AM +0800, Stas Bekman wrote:
> I've a bunch of them, but I think that the one in /lib/ that's used:
>
> % urpmf libthread_db
> glibc:/lib/libthread_db-1.0.so
> glibc:/lib/libthread_db.so.1
> glibc_lsb:/lib/lsb/libthread_db-1.0.so
> glibc_lsb:/lib/lsb/libthread_db.so.1
> glibc-devel:/usr/lib/libthread_db.so
> glibc_lsb-devel:/usr/lib/lsb/libthread_db.so
>
> what should I ldd to figure out which one is used?
Well, what version of the glibc RPM is installed? (glibc, not any of
the others). My bet is that his is just broken somehow; I recall a
recent version having that problem.
> >Also, you might want to see if setting auto-solib-add to 0 speeds you
> >up. You'll need to add them by hand (I think "sharedlibrary" or "info
> >sharedlibrary" will do it) before setting breakpoints in them, but that
> >may be fine for your use.
>
>
> Whoah! That makes a huge difference!
>
> with this -commands file:
>
> handle SIGPIPE pass
> handle SIGPIPE nostop
> set auto-solib-add 0
> b apr_poll
> run -DONE_PROCESS -d /home/stas/apache.org/mp-subproc/t -f
> /home/stas/apache.org/mp-subproc/t/conf/httpd.conf -DAPACHE2
> -DPERL_USEITHREADS
>
> I get the gdb prompt in less than 5 secs! That's so sweet :) the only
> problem now is that I need to craft gdb command files to load the
> symbols that I want to debug, but I can live with that.
>
> I can see what shared libraries it has loaded (without reading the
> symbol table) with 'info sharedlibrary' and then I force gdb to read the
> symbols from the wanted library using 'sharedlibrary regex' and voila, I
> can set the breakpoint.
>
> Thanks a lot for this very timely help, Daniel!
Glad to help. Now back to fixing the actual problems...
> While we are on this topic, do you know of a good book about gdb, shared
> libs, symbols, linking and stuff? The manuals are useful, but I'm really
> looking for a good book about this material, as I see many books that
> mention a bit but none does indepth coverage. The book "PANIC! UNIX
> System Crash, Dump Analysis" seems to be exactly what I'm looking for,
> but it's not very useful as it uses Sun's proprietary tools :(
Nope, sorry. There needs to be a good one published :)
--
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
Re: perlrequire/perlmodule are running twice and slow
Posted by Stas Bekman <st...@stason.org>.
Daniel Jacobowitz wrote:
> On Mon, Nov 26, 2001 at 06:18:43PM +0800, Stas Bekman wrote:
>
>>Daniel Jacobowitz wrote:
>>
>>
>>
>>>>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).
>>>
>>
>>I've checked, Philippe has libthread_db and running the same gdb version
>>(the same release but he is on RH, while I'm on Mandrake Linux).
>>
>
> Interesting. Perhaps RH had a separate patch applied; which version is
> this?
I've a bunch of them, but I think that the one in /lib/ that's used:
% urpmf libthread_db
glibc:/lib/libthread_db-1.0.so
glibc:/lib/libthread_db.so.1
glibc_lsb:/lib/lsb/libthread_db-1.0.so
glibc_lsb:/lib/lsb/libthread_db.so.1
glibc-devel:/usr/lib/libthread_db.so
glibc_lsb-devel:/usr/lib/lsb/libthread_db.so
what should I ldd to figure out which one is used?
> Also, you might want to see if setting auto-solib-add to 0 speeds you
> up. You'll need to add them by hand (I think "sharedlibrary" or "info
> sharedlibrary" will do it) before setting breakpoints in them, but that
> may be fine for your use.
Whoah! That makes a huge difference!
with this -commands file:
handle SIGPIPE pass
handle SIGPIPE nostop
set auto-solib-add 0
b apr_poll
run -DONE_PROCESS -d /home/stas/apache.org/mp-subproc/t -f
/home/stas/apache.org/mp-subproc/t/conf/httpd.conf -DAPACHE2
-DPERL_USEITHREADS
I get the gdb prompt in less than 5 secs! That's so sweet :) the only
problem now is that I need to craft gdb command files to load the
symbols that I want to debug, but I can live with that.
I can see what shared libraries it has loaded (without reading the
symbol table) with 'info sharedlibrary' and then I force gdb to read the
symbols from the wanted library using 'sharedlibrary regex' and voila, I
can set the breakpoint.
Thanks a lot for this very timely help, Daniel!
While we are on this topic, do you know of a good book about gdb, shared
libs, symbols, linking and stuff? The manuals are useful, but I'm really
looking for a good book about this material, as I see many books that
mention a bit but none does indepth coverage. The book "PANIC! UNIX
System Crash, Dump Analysis" seems to be exactly what I'm looking for,
but it's not very useful as it uses Sun's proprietary tools :(
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: perlrequire/perlmodule are running twice and slow
Posted by Daniel Jacobowitz <dm...@andrew.cmu.edu>.
On Mon, Nov 26, 2001 at 06:18:43PM +0800, Stas Bekman wrote:
> Daniel Jacobowitz wrote:
>
>
> >>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).
>
>
> I've checked, Philippe has libthread_db and running the same gdb version
> (the same release but he is on RH, while I'm on Mandrake Linux).
Interesting. Perhaps RH had a separate patch applied; which version is
this?
Also, you might want to see if setting auto-solib-add to 0 speeds you
up. You'll need to add them by hand (I think "sharedlibrary" or "info
sharedlibrary" will do it) before setting breakpoints in them, but that
may be fine for your use.
--
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
Re: perlrequire/perlmodule are running twice and slow
Posted by Stas Bekman <st...@stason.org>.
Daniel Jacobowitz wrote:
>>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).
I've checked, Philippe has libthread_db and running the same gdb version
(the same release but he is on RH, while I'm on Mandrake Linux).
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: perlrequire/perlmodule are running twice and slow
Posted by Daniel Jacobowitz <dm...@andrew.cmu.edu>.
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
Re: perlrequire/perlmodule are running twice and slow
Posted by Stas Bekman <st...@stason.org>.
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:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: perlrequire/perlmodule are running twice and slow
Posted by Daniel Jacobowitz <dm...@andrew.cmu.edu>.
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.
Just be glad you aren't linked to -lpthread. Then it REALLY takes
forever.
--
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
Re: perlrequire/perlmodule are running twice and slow
Posted by Stas Bekman <st...@stason.org>.
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.
>>Also this shows that BEGIN block of startup.pl is running twice. I don't
>>think this is right. (BTW, people are still reporting this problem with
>>mod_perl 1.26!)
>
> it is right. and also right with 1.26, if modperl is built as a dso.
so under DSO on restart perl is torned down. Please explain then why the
require of the startup file on restart is immediate? something that has
to do with gdb caching the symbol tables? so it's gdb spending 14
seconds reading something in?
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: perlrequire/perlmodule are running twice and slow
Posted by Doug MacEachern <do...@covalent.net>.
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.
> Also this shows that BEGIN block of startup.pl is running twice. I don't
> think this is right. (BTW, people are still reporting this problem with
> mod_perl 1.26!)
it is right. and also right with 1.26, if modperl is built as a dso.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org