From jura05@narod.ru

Created by jura05@jura05-desktop.nonet

Flags:
    category=core
    severity=medium

Site configuration information for perl 5.12.0:

Configured by jura05 at Sat May 22 02:10:50 MSD 2010.

Summary of my perl5 (revision 5 version 12 subversion 0) configuration:
   
  Platform:
    osname=linux, osvers=2.6.24-23-generic, archname=i686-linux
    uname='linux jura05-desktop 2.6.24-23-generic #1 smp mon jan 26 00:13:11 utc 2009 i686 gnulinux '
    config_args='-des -Dprefix=/home/jura05/localperl'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=undef, usemultiplicity=undef
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=undef, use64bitall=undef, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2',
    cppflags='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
    ccversion='', gccversion='4.2.4 (Ubuntu 4.2.4-1ubuntu3)', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=4, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lnsl -ldl -lm -lcrypt -lutil -lc
    perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
    libc=/lib/libc-2.7.so, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version='2.7'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
    cccdlflags='-fPIC', lddlflags='-shared -O2 -L/usr/local/lib -fstack-protector'

Locally applied patches:
    


@INC for perl 5.12.0:
    /home/jura05/localperl/lib/site_perl/5.12.0/i686-linux
    /home/jura05/localperl/lib/site_perl/5.12.0
    /home/jura05/localperl/lib/5.12.0/i686-linux
    /home/jura05/localperl/lib/5.12.0
    .


Environment for perl 5.12.0:
    HOME=/home/jura05
    LANG=en_US.UTF-8
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
    PERL_BADLANG (unset)
    SHELL=/bin/bash

From @ikegami

tye providede some insight on PerlMonks​:

"Perl weak references are implemented as a singly-linked list.
Destroying a weak reference is thus O(n) if you have n weak references
to a particular variable. So destroying N weak references to the same
variable is O(n**2)."

The RT System itself - Status changed from 'new' to 'open'

From @iabyn

On Fri, May 21, 2010 at 04​:07​:10PM -0700, ЮÑ�ий Ð�алÑ�Ñ�ин wrote​:

I found that garbage collection after weakening is
extemely slow in some cases. Here is the code​:

#!/usr/bin/perl -w use strict;
use Scalar​::Util qw(weaken);

my @​data = (1, 2, 3);
print time, " test 0​: main start\n";
&gogogo();
print time, " test 3​: main end\n";

sub gogogo {
print time, " test 1​: func start\n";
my @​h;
for (1 .. 200000) {
my %hash = (data => \@​data);
weaken($hash{data});
push @​h, \%hash;
}
print time, " test 2​: func end\n"
; }

Timing​:

1273747847 test 0​: main start
1273747847 test 1​: func start
1273747847 test 2​: func end
1273747873 test 3​: main end

Now fixed (for an exceedingly loose definition of "fixed") with the
following commit​:

commit 51bc437b0a4f1acf50b83c3c4507532aee3c4977
Author​: David Mitchell <davem@​iabyn.com>
AuthorDate​: Sun Oct 31 17​:01​:10 2010 +0000
Commit​: David Mitchell <davem@​iabyn.com>
CommitDate​: Sun Oct 31 17​:12​:46 2010 +0000

  RT 75254​: Slow GC after Scalar​::Util​::weaken
 
  Freeing lots of weak RVs to the same object results in quadratic
  search through the backrefs array. This is probably sufficiently rare
  that its not worth the expense of replacing the array with a ptr table
  (say); but in the meantime, this patch makes the code as tight as
  possible, and adds a check for the sv being at element 0, so that
  both types of linear create/destroy order are optimised (previously only
  created last / deleted first order was quick). It's still slow for random
  deletion order. The RT code, modified to give high-res timing for the
  return from the sub, and with various types of destruct order, gives the
  following timings​:
 
  LIFO FIFO random
  before 0.05s 17.37s 17.28s
  now 0.04s 0.04s 12.05s

M sv.c

--
"Procrastination grows to fill the available time"
  -- Mitchell's corollary to Parkinson's Law

@iabyn - Status changed from 'open' to 'resolved'

From @iabyn

apparently I failed to push that commit. Now in as commit
51698cb