Intriguing indeed. Especially as there is such close correspondance betwen our standard Perl runtimes, and such disparity with the autoboxed version. I'm at a loss ot explain it. (Could you try running with the command line options show below?).

Perhaps a few others could run the code--with emphasis on AS & non-AS Perl's on Windows; 32-bit & 64-bit; threaded & non-threaded--though you seem to have ruled that out. Maybe they would shed some light.

This is a direct, unedited c&p from my console running first the standard Perl version on 4000, and then the autoboxed version on 400-4000 showing the exponential growth in runtime:

C:\test>826456 -N=4000
4000: Took 1.367 seconds

C:\test>826456-a -N=400
400: Took 0.025 seconds

C:\test>826456-a -N=800
800: Took 0.988 seconds

C:\test>826456-a -N=1600
1600: Took 13.999 seconds

C:\test>826456-a -N=3200
3200: Took 119.228 seconds

C:\test>826456-a -N=4000
4000: Took 234.037 seconds
[download]

My system is

C:\test>perl -V
Summary of my perl5 (revision 5 version 10 subversion 1) configuration
+:

  Platform:
    osname=MSWin32, osvers=5.2, archname=MSWin32-x64-multi-thread
    uname=''
    config_args='undef'
    hint=recommended, useposix=true, d_sigaction=undef
    useithreads=define, usemultiplicity=define
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=und
+ef
    use64bitint=define, use64bitall=undef, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cl', ccflags ='-nologo -GF -W3 -MD -Zi -DNDEBUG -Ox -GL -Wp64 
+-fp:precise -DWIN32 -D_CON
    optimize='-MD -Zi -DNDEBUG -Ox -GL -Wp64 -fp:precise',
    cppflags='-DWIN32'
    ccversion='15.0.21022', gccversion='', gccosandvers=''
    intsize=4, longsize=4, ptrsize=8, doublesize=8, byteorder=12345678
    d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=8
    ivtype='__int64', ivsize=8, nvtype='double', nvsize=8, Off_t='__in
+t64', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='link', ldflags ='-nologo -nodefaultlib -debug -opt:ref,icf -lt
+cg  -libpath:"C:\Perl64\li
    libpth=\lib
    libs=  oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib
+  comdlg32.lib advapi32.li
    perllibs=  oldnames.lib kernel32.lib user32.lib gdi32.lib winspool
+.lib  comdlg32.lib advapi3
    libc=msvcrt.lib, so=dll, useshrplib=true, libperl=perl510.lib
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
    cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -debug -opt:
+ref,icf -ltcg  -libpath:"C


Characteristics of this binary (from libperl):
  Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV
                        PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS
                        PERL_MALLOC_WRAP PL_OP_SLAB_ALLOC USE_64_BIT_I
+NT
                        USE_ITHREADS USE_LARGE_FILES USE_PERLIO
                        USE_SITECUSTOMIZE
  Locally applied patches:
        ActivePerl Build 1006 [291086]
        32728 64-bit fix for Time::Local
  Built under MSWin32
  Compiled at Aug 24 2009 13:45:20
  @INC:
    C:/Perl64/site/lib
    C:/Perl64/lib
    .

C:\test>perl -Mautobox -E"say $autobox::VERSION"
2.55

C:\test>perl -Mautobox::Core -E"say $autobox::Core::VERSION"
0.6
[download]

Full console log including dumping sources to the screen:

My run of the test on perl-5.10.1 (linux-amd64) confirms cromatics' findings:

luben@karavelov:~/perl$ ./t -N=4000
4000: Took 2.062 seconds
luben@karavelov:~/perl$ ./tac -N=4000
4000: Took 2.538 seconds
[download]

And the perl version:

luben@karavelov:~/perl$ perl -V
Summary of my perl5 (revision 5 version 10 subversion 1) configuration
+:
   
  Platform:
    osname=linux, osvers=2.6.32-trunk-amd64, archname=x86_64-linux-gnu
+-thread-multi
    uname='linux madeleine 2.6.32-trunk-amd64 #1 smp sun jan 10 22:40:
+40 utc 2010 x86_64 gnulinux '
    config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN -Dccc
+dlflags=-fPIC -Darchname=x86_64-linux-gnu -Dprefix=/usr -Dprivlib=/us
+r/share/perl/5.10 -Darchlib=/usr/lib/perl/5.10 -Dvendorprefix=/usr -D
+vendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/
+usr/local -Dsitelib=/usr/local/share/perl/5.10.1 -Dsitearch=/usr/loca
+l/lib/perl/5.10.1 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/
+man/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/m
+an/man3 -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -
+Uafs -Ud_csh -Ud_ualarm -Uusesfio -Uusenm -DDEBUGGING=-g -Doptimize=-
+O2 -Duseshrplib -Dlibperl=libperl.so.5.10.1 -Dd_dosuid -des'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=define, usemultiplicity=define
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=und
+ef
    use64bitint=define, use64bitall=define, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  ...
Characteristics of this binary (from libperl): 
  Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV
                        PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP USE_64_
+BIT_ALL
                        USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES
                        USE_PERLIO USE_REENTRANT_API
...
[download]

The versions of autobox and autobox::Core are the same as yours. May be it is a problem with the windows version of perl.

The cause is memory growth! Despite that they both process identical datsets:

• The perl version grabs 6.2MB of ram immediately, and then terminates.

  Memory without autobox

• The autobixed version starts at about 40MB and then slowly grabs more and more memory until it finally finishes with over 300MB.

  Memory with autobox

I'd be interested to hear if the autobox also grabs a heap of memory on your systems?

I also instrumenting them both with NYTProf, but the output is so bewildering (and large) that I'm not able to make any sense of it. If there is anyone out there that wants to try and fix this, I'll make the NYTProf output, plus any other info I can supply, to them.

Hm. You weren't by any chance using version 0.7 when you ran your tests? With a few tweaks maybe?

Because

1. I posted my meditation Mar 04, 2010 at 20:33 GMT.
2. Version 0.7 was apparently uploaded on 4th March.
3. You posted your reply Mar 05, 2010 at 05:02 GMT

My hat's off to Scott Walters for such a fast response. Especially on a module he hadn't had occasion to touch for two years.