Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Slow GC after Scalar::Util::weaken #10399

p5pRT opened this issue May 21, 2010 · 6 comments

Slow GC after Scalar::Util::weaken #10399

p5pRT opened this issue May 21, 2010 · 6 comments


Copy link

p5pRT commented May 21, 2010

Migrated from (status was 'resolved')

Searchable as RT75254$

Copy link

p5pRT commented May 21, 2010


Created by jura05@jura05-desktop.nonet

Perl Info


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:
    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
    cc='cc', ccflags ='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    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/, so=so, useshrplib=false, libperl=libperl.a
  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:

Environment for perl 5.12.0:
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PERL_BADLANG (unset)

Copy link

p5pRT commented Jun 3, 2010

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

Copy link

p5pRT commented Jun 3, 2010

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

Copy link

p5pRT commented Oct 31, 2010

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";
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);
push @​h, \%hash;
print time, " test 2​: func end\n"
; }


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@​>
AuthorDate​: Sun Oct 31 17​:01​:10 2010 +0000
Commit​: David Mitchell <davem@​>
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

Copy link

p5pRT commented Oct 31, 2010

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

@p5pRT p5pRT closed this as completed Oct 31, 2010
Copy link

p5pRT commented Nov 1, 2010

From @iabyn

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

1 participant