Re: Re: Re: Extreme Example of TMTOWTDI

[Dice]

As has been pointed out before, the fundamental cause of the slowness of your orginal code is that you are doing an open/write/close operation for each input line. That's no good -- open and close are slow things to do.

Here's something else you can consider -- anonymous open filehandles aggregated and managed within a container.

Huh?

Check it out...

I created 2 programs. make_words.pl that creates some number of words (well, string of "a" of length between 1 and 10) and file_words.pl that puts them into files named LENGTH.words. I run them together, with: ./make_words.pl 100 | ./file_words.pl (The 100 is the number of "words" I want to generate.)

---

make_words.pl

#!/usr/bin/perl -w

use strict;

my $len;

foreach ( 1 .. $ARGV[0] ) {
    my $len = (int(10 * rand())) + 1;
    print (('a' x $len), "\n");
}

exit 0;

---

file_words.pl

#!/usr/bin/perl -w

use strict;
# use Data::Dumper;

my @filehandles = ();

while ( my $word = <> ) {

    my $len = length($word) - 1;

#    print Dumper(\@filehandles);

    unless ( $filehandles[$len] ) {

	open($filehandles[$len], "> $len.words") or do {
	    warn "$len.words already exists!\n";
	    next;
	};
    }
    print {$filehandles[$len]} $word;
}

foreach ( @filehandles ) {
    close($_) if $_;
}

exit 0;

make_words.pl is too simple for analysis. (Right?)

In file_words.pl, I create an array that is meant to store my anonymous filehandles. Of coure, there isn't anything in it at the begining of the program.

Looping through all the words, I determine the length of the word in question. (Why bother chomp-ing? We'll use the newline later).

Then, I want to write the word to the file. The next thing to do is to open an appropriately-named filehandle for writing... unless there already is an appropriate filehandle. In which case, just print the word to that filehandle.

Notice that I'm using a scalar as my filehandle. Perl will autovivify an anonymous filehandle and assign it to that scalar, assuming it's an assignable scalar... such as what can be found in an array element. (The array is my aggregator -- I aggregate [collect] my filehandles within it.)

At the end of the program, I go through my array and close any filehandles that are stored within it. I don't just want to close every element in the array, as some of them might be "undef" values.

Note that if you uncomment the 2 commented lines, you'll get some data-dumper output that shows you the gradual population of elements within the @filehandles array with anon filehandles.

Note that older version of Perl 5 won't support this kind of filehandle autovivification of empty assignable scalars. (In which case, you can still use this technique, but with minor modifications. But ask me about this later if you like.)

Here's a bit of a screencapture of the whole procedure...

rdice@tanru:~/tmp/test$ rm *.words; ./make_words.pl 100 | ./file_test.pl
rdice@tanru:~/tmp/test$ wc -l *.words
      8 1.words
     11 10.words
      8 2.words
     15 3.words
      7 4.words
     11 5.words
     10 6.words
      9 7.words
     10 8.words
     11 9.words
    100 total

Cheers,
Richard

[demerphq]

Actually the create a filehandle on demand is not as efficient as building the array (on any box with a reasonable amount of memory that is.) If you have a look at my earlier comment this is exactly the technique that I used in my solution, and it required some counter-intuitive tweaking before it became competetive with the array building technique.

The reason seems to be twofold. First the reading loop has a higher overhead because it needs to do an extra operation per line read. Second it seems that there is an overhead associated with swapping between cached filehandles. Before my solution was competetive (and it started life looking much the same as your solution) I had to replace the open on demand, with a preopen for each file (which obviously is only feasible in some situations).

Anyway, nice explanation of the technique.

Yves / DeMerphq
---
Writing a good benchmark isnt as easy as it might look.