in reply to 4Re: Substituting Newline Characters
in thread Substituting Newline Characters

We do stuff dealing with billions of records so those little bits add up. Anyway it benches 4 times faster as you might expect. It is a tribute to p5p that it is only 4 times slower. I have actually defactored some code recently for example. We have a merge and an unmerge function, very similar code so I added a flag and a couple of if clasues so the unmerge was just another call to merge with the flag set. You know the usual stuff. But those two extra ifs every loop added 30% to the runtime - for both functions. So I had less code, although it was more complex but killed the runtime.

In my version of the real world my fixed costs are servers and bandwidth. The more efficient I can make my code in terms of memory use and throughput the more clients we can shoehorn onto a single server which directly hits the bottom line. Compact functions are also easier to unit test which helps stability. As always YMMV. Whatever works for you is all you need.

cheers

tachyon

  • Comment on Re: 4Re: Substituting Newline Characters

Replies are listed 'Best First'.
Re^6: Substituting Newline Characters
by Aristotle (Chancellor) on Mar 16, 2004 at 14:20 UTC
    Cases like your merge/unmerge are really what a macro system is for. Failing that (which Perl does, up until Perl 6), you can use either eval (in simple cases) or a templating engine (in not so simple cases) to generate code for similar things from a common source and still do it Once And Only Once.

    Makeshifts last the longest.

[reply]

      I was suprised by the performance hit. In essence the only change was 2x if/else cases added 

      sub merge {
    my ( $data, $unmerge ) = @_;
    while ( $some_condition ) {
        # big loop, no embedded loops
        $count = $unmerge ? $count1 + $count2 : $count1 - $count 2;
    }
}

      [download]

      As you say a preprocessor of some description could optimise the flag away, depending on the call. eval might well have allowed perl to optimise the code getting rid of the repeated if checks that will either always be true or always be false. But by the time I had added an AUTOLOAD the code would have been a lot less transparent and physically almost as long. I had not thought about using eval to delay compilation and effectively allow you to stub the functions and get them to compile more efficiently. I may give it a benchmark when I have a chance.

      cheers

      tachyon

[reply]
[d/l]
        No no, I mean eval to generate two near-identical subs at compile time — no AUTOLOAD funkiness or anything. 
        BEGIN {
    my $merge_code = <<'EOC';
    sub %s {
        my ($data) = @_;
        while ( $some_condition ) {
            # big loop, no embedded loops
            $count = $count1 %s $count2;
        }
    }
EOC

    eval sprintf $merge_code, merge => '+';
    eval sprintf $merge_code, unmerge => '-';
}

        [download]
        I think it's very clear what's going on here, and you still get the benefit of only maintaining a single copy of the code.

        Makeshifts last the longest.

[reply]
[d/l]

In Section Seekers of Perl Wisdom