Bug in 5.8.0? . op is very slow

[Matthias Weckman]

Hi all,

I hope you may be able to shed some light on this.
I'm using ActiveState Perl 5.8.0 (build 806) on Windows 2000, and
noticed that slurping a file was very slow compared to the old 5.6.1.

I narrowed it down to the . operator taking a lot of time, see the
script below.

I tried searching the web for some info on this, but couldn't find
anything on Google, bugs.perl.org or activestate.com.

Is this an issue with ActiveState's build only? Or is it a 5.8.0 issue
in general? Do you know if it has been fixed in 5.8.1?
Is there a way to improve this?

Unfortunately I do not have access to other versions of perl on other
platforms, so I can't compare.

Thanks,
Matthias

---8<---

use strict;
use warnings;
use Benchmark qw(timeit timestr);

my $c = 10;
my $t = timeit ($c, q!
my $x = '';
my $y = 'x' x 10000;
my $z = 0;
while($z < 7000000)
{
$z+=10000;
$x .= $y;
}
!
);
print "$c loops of concat took:",timestr($t),"\n";

__END__
Results for ActiveState Perl 5.8.0 build 806 On Win2K SP4:
10 loops of concat took:34 wallclock secs (19.13 usr + 13.54 sys = 32.67
CPU) @ 0.31/s (n=10)

Results for ActiveState Perl 5.6.1 build 635 On Win2K SP4:
10 loops of concat took: 1 wallclock secs ( 0.39 usr + 0.03 sys = 0.42
CPU) @ 23.81/s (n=10)

 

[Sisyphus]

---8<---

use strict;
use warnings;
use Benchmark qw(timeit timestr);

my $c = 10;
my $t = timeit ($c, q!

my $x = '0' x 7000000;
$x = '';

my $y = 'x' x 10000;
my $z = 0;
while($z < 7000000)
{
$z+=10000;
$x .= $y;
}
!
);
print "$c loops of concat took:",timestr($t),"\n";

__END__
Results for ActiveState Perl 5.8.0 build 806 On Win2K SP4:
10 loops of concat took:34 wallclock secs (19.13 usr + 13.54 sys = 32.67
CPU) @ 0.31/s (n=10)

Results for ActiveState Perl 5.6.1 build 635 On Win2K SP4:
10 loops of concat took: 1 wallclock secs ( 0.39 usr + 0.03 sys = 0.42
CPU) @ 23.81/s (n=10)

Dunno what the exact problem is but I'm finding the same with AS perl on
2k SP3.

5.6.1 takes around 0.8 seconds
5.8.0 around 23 seconds

With the alterations (above) to your script, I find it runs about 10
times faster on 5.8.0, but 2.5 times slower on 5.6.1.

ie:
5.6.1 takes around 1.9 seconds
5.8.0 around the same (1.9 seconds).

Looks like it has something to do with the way memory is being allocated
- more to do with the fact that $x needs more and more memory, rather
than the '.' operator per se.

Cheers,
Rob

 

[Anno Siegel]

[concatenation is slow]

use strict;
use warnings;
use Benchmark qw(timeit timestr);

my $c = 10;
my $t = timeit ($c, q!
my $x = '';
my $y = 'x' x 10000;
my $z = 0;
while($z < 7000000)
{
$z+=10000;
$x .= $y;
}
!
);
print "$c loops of concat took:",timestr($t),"\n";

__END__
Results for ActiveState Perl 5.8.0 build 806 On Win2K SP4:
10 loops of concat took:34 wallclock secs (19.13 usr + 13.54 sys = 32.67
CPU) @ 0.31/s (n=10)

Results for ActiveState Perl 5.6.1 build 635 On Win2K SP4:
10 loops of concat took: 1 wallclock secs ( 0.39 usr + 0.03 sys = 0.42
CPU) @ 23.81/s (n=10)

Well, that's a ridiculous time difference. I don't see anything similar
on a linux box -- 5.6.1 and 5.8.0 run your benchmarks in similar time
for me.

Anno

 

[Simon Andrews]

Hi all,

I hope you may be able to shed some light on this.
I'm using ActiveState Perl 5.8.0 (build 806) on Windows 2000, and
noticed that slurping a file was very slow compared to the old 5.6.1.

I narrowed it down to the . operator taking a lot of time, see the
script below.

use strict;
use warnings;
use Benchmark qw(timeit timestr);

my $c = 10;
my $t = timeit ($c, q!
my $x = '';
my $y = 'x' x 10000;
my $z = 0;
while($z < 7000000)
{
$z+=10000;
$x .= $y;
}
!
);
print "$c loops of concat took:",timestr($t),"\n";

__END__
Results for ActiveState Perl 5.8.0 build 806 On Win2K SP4:
10 loops of concat took:34 wallclock secs (19.13 usr + 13.54 sys = 32.67
CPU) @ 0.31/s (n=10)

Results for ActiveState Perl 5.6.1 build 635 On Win2K SP4:
10 loops of concat took: 1 wallclock secs ( 0.39 usr + 0.03 sys = 0.42
CPU) @ 23.81/s (n=10)

I can confirm this on my Win32 boxes.

5.8.0 (AS Build 806) 23 wallclock secs
5.6.1 (AS Build 635) 1 wallclock sec

...but not under Linux

5.8.0 (Linux) 0 wallclock secs
5.6.1 (Linux) 0 wallclock secs

....so it looks like an AS thing. I don't have any other 5.8 AS builds
to try out though so it may be just a 635 problem.

Simon.

 

[Sisyphus]

...so it looks like an AS thing. I don't have any other 5.8 AS builds
to try out though so it may be just a 635 problem.

I was using builds 626 and 802 - so it looks like the anomaly has been
there for a while - and possibly still is



Cheers,
Rob

 

[A. Sinan Unur]

I can confirm this on my Win32 boxes.

5.8.0 (AS Build 806) 23 wallclock secs
5.6.1 (AS Build 635) 1 wallclock sec

Just FYI: I can't.

System: 1 Ghz Celeron w 512 Mb RAM Win XP Pro Sp 1
AS perl v.5.8.0 build 806

Result:

10 loops of concat took: 2 wallclock secs ( 1.76 usr + 0.01 sys = 1.77
CPU) @ 5.64/s (n=10)

Sinan

 

[Matthias Weckman]

I can reproduce this only on our W2K Servers,
ServicePack 3. No Problem on W2K Prof SP4.
So maybe it depends on ServicePack or Prof/Server
versions? Don't have any SP3 Workstations or
SP4 Servers here to test at the moment, so I
can't investigate this any further.

Well, I've tried it on some other machines as well, and didn't see the
effect on W2K Server SP3 or SP4, nor on W2003 Server.

Very strange.

Anyway, thank you for your input! Glad to see it isn't just me, and
sorry to see that this really is an issue.

Does anyone know how I would go about finding info in the various bug
databases? Searching Activestate's one on 'memory' didn't show me
anything relevant (I think).
Would it make sense to file a bug report?

Cheers
-Chris

Matthias

 

[Sisyphus]

Just FYI: I can't.

System: 1 Ghz Celeron w 512 Mb RAM Win XP Pro Sp 1
AS perl v.5.8.0 build 806

Result:

10 loops of concat took: 2 wallclock secs ( 1.76 usr + 0.01 sys = 1.77
CPU) @ 5.64/s (n=10)

Sinan

That's still pretty slow compared to my 1 Ghz Pentium with 5.6.1 which
takes 0.8 seconds .... still, it's a big improvement on 23 seconds

Perhaps there's something in the later 2k service packs that makes the
situation worse.

Cheers,
Rob

 

[Sisyphus]

Well, I've tried it on some other machines as well, and didn't see the
effect on W2K Server SP3 or SP4, nor on W2003 Server.

Very strange.

Anyway, thank you for your input! Glad to see it isn't just me, and
sorry to see that this really is an issue.

Does anyone know how I would go about finding info in the various bug
databases? Searching Activestate's one on 'memory' didn't show me
anything relevant (I think).
Would it make sense to file a bug report?

Maybe raise it first on ActiveState's 'perl-win32-users' mailing list.
Jan Dubois could likely provide some relevant input - AS might even
already know about it. Mark the post 'ATTN: Jan' or something like that
to make sure he sees it.

Cheers,
Rob

 

[Dan Rawson]

Well, I've tried it on some other machines as well, and didn't see the
effect on W2K Server SP3 or SP4, nor on W2003 Server.

[Snip]

As an FYI, I get the same effect on NT SP6a, so it's not limited to Win2k (less than 1 sec with build 629, 19 seconds with build 835)

Dan

 

[Dan Rawson]

Hi all,

I hope you may be able to shed some light on this.
I'm using ActiveState Perl 5.8.0 (build 806) on Windows 2000, and
noticed that slurping a file was very slow compared to the old 5.6.1.

I narrowed it down to the . operator taking a lot of time, see the
script below.

Is this an issue with ActiveState's build only? Or is it a 5.8.0 issue
in general? Do you know if it has been fixed in 5.8.1?
Is there a way to improve this?

This appears to be only in the Win32 ActiveState builds; build 806 / 635 on Solaris don't exhibit the same behavior. Our source builds on Solaris also don't display the same behavior.

Filed as bug 28167 at ActiveState (cf also bug 26762).
http://bugs.activestate.com/show_bug.cgi?id=28167

Dan