in reply to Fast morphing of SYBASE data to flat-file

Well, you're sasify'ing each of the fields individually, then sasify'ing them all again when you put them into the line (although this could be necessary, you appear to be stripping the delimiting pipe symbols for a reason). I'd do something like:

my $fields_string = join "|", @$rowref; my $line = sasify($fields_string);

That's one call to the subroutine rather than 5.

Another comment: you're asking Perl to compile each of the regular expressions again every time the subroutine sasify is called. You can avoid this with the "/o" operator (stick an 'o' next to the 'g' at the end of each regex). This tells Perl to compile the regex *only* once for the entire course of the program. IIRC the tr operator - see perldoc perlop or perlop - is reported to be faster for delete operations. You may wish to try something like (untested; I'm not too hot on the tr operator):

$in =~ tr/^\| *//d;
Hope that Helps
davis
Is this going out live?
No, Homer, very few cartoons are broadcast live - it's a terrible strain on the animator's wrist

Update: Minor typographical changes

Replies are listed 'Best First'.
Re (2): Fast morphing of SYBASE data to flat-file
by VSarkiss (Monsignor) on Mar 13, 2003 at 17:40 UTC

    you're asking Perl to compile each of the regular expressions again every time the subroutine sasify is called. You can avoid this with the "/o" operator
    This is a common misconception. In fact, the regular expressions are compiled once, at the same time as the rest of the program. The /o modifier makes a difference only when the RE includes a variable interpolation: in that case, it means the RE will contain the value of the variable at its first use, and will not change, regardless of whether the variable changes or not. In this case, since the REs are static strings, there is no re-compilation involved.

      I'd like to add to this, "Just don't use /o!"

      It was useful in Perl4. In Perl5 it is not very useful (the performance gain it provides is small and not as good as that provided by better alternatives) and it is confusing to the point of causing bugs.

      If you haven't identified a performance problem, then don't worry about it. If you have, then use qr// (if you have regular expression that contain variables).

                      - tye