in reply to Re: Function call in regex replacement string
in thread Function call in regex replacement string

I agree with two of your points.

I vehemently disagree with the first one : "regex is better than pack/unpack".
Almost never is regex is better than pack/unpack


Almost never is even substr is better than pack/unpack

Please go ahead and disagree with facts on the table.

What would ever make you things like that?

In fact this post gives me the idea for some discussion I have been wanting to have for a long time.. the misuse of things like regex and substr etc which makes PERL ever so slow in runtime than it really should be.
  • Comment on Re^2: Function call in regex replacement string

Replies are listed 'Best First'.
Re^3: Function call in regex replacement string
by Marshall (Canon) on Feb 25, 2009 at 10:23 UTC
    Well like I said, except in cases where you know for sure that you have a fixed column alignment. Virtually all the data that I work with does not have fixed byte alignment. And in some of the files I work with, even if alignment is "fixed", the alignment shifts when some new release comes out of the other program. There are always trade-offs between efficiency and maintainability, etc.

    I've done some testing with the regex engine in Perl 5.10 vs Perl 5.8 and earlier....its a LOT faster now. I've got one application that does a LOT of I/O and I've been considering using Storable for intermediate steps. This of course uses byte stream (and pack/unpack) to dump and re-create internal Perl structures. At the end of the day, final output will be in ASCII format of some type.

    Most performance issues that I've found can be traced to improper algorithm or just flawed implementation. Perl allows very sophisticated algorithms to be implemented quickly and better algorithms can make a big difference! I can write Perl code about 5-10x faster than in C. Code runs maybe 1/3 the speed of C. So there are trade-offs!

    I've seen some really bad code here on Monks and some of it will run just like a "herd of turtles". Sometimes that doesn't matter and sometimes it does!

    So I guess this a "your mileage may vary" sort of thing.

    Update:Now that I think more about this, misuse of OO techniques is probably a far greater performance hit. The OO performance hit is about 30%. This stuff is great for DB, GUI, but I've seen some situations where it is just plain goofy.

      Yes you are completely correct in your scenario. Its much better to use regex when unpack can be often thrown out because of changing length...

      One question : Do you embed your regexes into code, or you put them as variables?

      I have never written PERL code that has run 1/3rd at the speed of similar C code - usually the values I get are around 1/20th median. Best I got was 1/10th.

      But I believe you. I had also read an article (but now I forget its contents and URI) that showed how we can optimize PERL by giving it hints and making appropriate use of functions.. I wold post a thread soon on this asking for more information... do you for example have any? (For eg, favouring unpack over substr etc)

      I frankly believe GUI makes a very bad case for OO (Object Oriented is what I mean), but yes, many things can be done better without OO, specially in cases when a UML digram was its predecessor.