print LIST join("\n", keys %wordlist, '');
[download]

Actually, that's an interesting question. With the one large string you have the overhead of allocating memory to append the string. I don't know any details in the internals of the memory management involved in that, but we know there is some overhead.

On the other hand, multiple prints with carriage returns will cause the stdio routines to flush to the file or console, so you're invoking the overhead of the system I/O routines for each line, as opposed until waiting for the one big line. And if it's not flushing ($| = 1), then you still have the overhead for the buffer management within stdio.

Anyone know any more details on that? Is it more efficient to let Perl do it's memory management on a big string, or let stdio do it's thing?

--Chris

e-mail jcwren

Well, in that case, go with my slow one:

print LIST map "$_\n", keys %wordlist;
[download]

At least, I think that'll be slightly faster than having one big fat string.

---

Update: duh. apparently not. So much for my gut level feel. Don't trust me anymore, I guess. {grin}

---

-- Randal L. Schwartz, Perl hacker

Well, taking nothing for granted (note, I did try larger arrays, fewer iterations, etc , and still got similar results):



use Benchmark;

my @arr=(0..10000);

open(FH1, '>file1') or die "file1: $!";
open(FH2, '>file2') or die "file2: $!";
open(FH3, '>file3') or die "file3: $!";

timethese(100, {
BIGJOIN=>\&bigjoin,
ITERATE=>\&iterate,
MAPIT=>\&mapit,
});

close FH1;
close FH2;
close FH3;

sub bigjoin {
 print FH1 join("\n", @arr, '');
}

sub iterate {
 print FH2 "$_\n" for @arr;
}

sub mapit {
 print FH3 map "$_\n" @arr;
}

>perl tst
Benchmark: timing 100 iterations of BIGJOIN, ITERATE, MAPIT...
   BIGJOIN:  3 wallclock secs ( 3.41 usr +  0.00 sys =  3.41 CPU) @ 29
+.33/s (n=100)
   ITERATE: 14 wallclock secs (13.57 usr +  0.00 sys = 13.57 CPU) @  7
+.37/s (n=100)
     MAPIT: 17 wallclock secs (16.86 usr +  0.00 sys = 16.86 CPU) @  5
+.93/s (n=100)
[download]