On Wed, 9 Aug 2000 09:23:02 -0400, John Porter wrote:
>That is way too simplistic. I for one think the current behavior
>of chomp() is ideal for its simplicity.
>
> while(<>) {
> /foo/ and next; # why bother chomping?
> if ( /bar/ ) {
> print; # why bother chomping?
> }
...
> }
It's not "simple". It's confusing. Very often I do stuff like you
describe, and then it turns out that there are cases where I needed the
chomp, and I forgot to add a newline. Argh. Edit the code, and run the
script again. ALWAYS or NEVER chomp is simpler.
If a built-in chomp() takes less than 1% of the time of reading the
line, and I'm 100% sure it can even be far less (cutting of a preknown
length of the a string is pretty damn fast), then why NOT do it?
I'm quite convinced that always implicit chomp can prove to be faster
than doing it for some cases, using an explicit perl keyword for a
fraction of the lines.
Say that we're talking about an overhead of under 0.3% of execution
time, with a turnover point at where less than 20% of the lines need the
chomp. Would you bother?
Note: if we become more liberal in what can mark a line end, say, regex
support instead of a plain fixed string, chomp() as currently used would
slow down quite a bit. An implicit chomp() need not to slow down at all
(i.e. a difference of under a microsecond), since we just found a string
that terminates the line, and thus we already know its length.
--
Bart.
