Paul Mineiro wrote:
right. i probably should've mentioned earlier that CGAT x 5 is
really fast in both mod_perl and command line.
if anybody wants my actual $seq data, please let me know.
i neglected to mention something big: the production version is
identical but using perl
Rob Mueller (fastmail) wrote:
I recently had a similar problem. A regex that worked fine in sample code
was a dog in the web-server code. It only happened with really long strings.
I tracked down the problem to this from the 'perlre' manpage.
WARNING: Once Perl sees that you need one of
Perrin Harkins wrote:
Your system has to be swapping horribly. I bet that the ulimit for
whoever apache is running as has the memory segment set super low.
apache is running as me on my unloaded desktop (no way this is going to
production until i figure this out). my ulimit -v is unlimited.
Robert Landrum wrote:
I just ran this on my system here... It's completely unloaded (load
average: 0.11, 0.08, 0.02)
Result:
0 wallclock secs ( 0.06 usr + 0.00 sys = 0.06 CPU) @ 16.67/s (n=1)
I ran it on a file that I created with
perl -e print 'ABCGEFSK' x 25000 /tmp/seqdata
for the patched version.
Parse::RecDescent makes heavy use of the above vars, no chance of fixing
that in a hurry.
Rob
- Original Message -
From: Paul Mineiro [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, January 24, 2002 11:01 AM
Subject: Re: slow regex [BENCHMARK]
Paul Mineiro
Rob Mueller (fastmail) wrote:
I recently had a similar problem. A regex that worked fine in sample code
was a dog in the web-server code. It only happened with really long strings.
I tracked down the problem to this from the 'perlre' manpage.
WARNING: Once Perl sees that you need
Paul Mineiro wrote:
i've cleaned up the example to tighten the case:
the mod perl code snippet is:
---
my @cg;
open DIL, '', /tmp/seqdata;
print DIL $seq;
close DIL;
warn length seq = @{[length ($seq)]};
my $t = timeit (1, sub {
while ($seq =~ /CG/g)
On Wed, 23 Jan 2002, Paul Mineiro wrote:
i've cleaned up the example to tighten the case:
the mod perl code snippet is:
Fascinating. The only thing I don't see is where $seq gets assigned to in
the CGI case. Where is the data coming from? Is it perhaps a tied
variable or otherwise unlike
At 4:01 PM -0800 1/23/02, Paul Mineiro wrote:
Paul Mineiro wrote:
i've cleaned up the example to tighten the case:
the mod perl code snippet is:
---
my @cg;
open DIL, '', /tmp/seqdata;
print DIL $seq;
close DIL;
warn length seq = @{[length ($seq)]};
my $t = timeit (1, sub {
Your system has to be swapping horribly. I bet that the ulimit for
whoever apache is running as has the memory segment set super low.
That's a possibility. I was also thinking that maybe mod_perl was built
against a different version of Perl, possibly one that has a problem
with this
hi. i'm running mod_perl 1.26 + apache 1.3.14 + perl 5.6.1
i have a loop in a mod_perl handler like so:
my $stime = time ();
while ($seq =~ /CG/og)
{
push @cg, pos ($seq);
}
my $etime = time ();
warn time was: , scalar localtime ($stime), ,
scalar
Paul Mineiro wrote:
hi. i'm running mod_perl 1.26 + apache 1.3.14 + perl 5.6.1
i have a loop in a mod_perl handler like so:
my $stime = time ();
while ($seq =~ /CG/og)
{
push @cg, pos ($seq);
}
my $etime = time ();
warn time was: , scalar localtime
under mod_perl this takes 23 seconds. running the perl by hand (via
extracting this piece into a seperate perl script) on the same data
takes
less than 1 second.
Are you sure that the string you're regex'ing is the same in both cases?
Why are you using the /o operator? CG isn't a variable,
13 matches
Mail list logo
