«

Hi,

Is it more efficient to use the destructive versions of functions in
Ruby? I know that in Lisp/Scheme destructive counterparts are usually
offered for efficiency reasons.

Can I assume that string.gsub! is preferable to string.gsub when I
know that the side-effect won't be affecting any other code?

I find the Ruby destructive operations sometimes inconvenient to use.
For example strip! might return null where strip would return a
string. However, if it's more efficient, I'd rather use the
destructive version.

Thanks,
Navin.

Hi

In message "Re: destructive! operations"
on Sun, 20 Feb 2005 17:22:34 +0900, Navindra Umanee <> writes:

|Is it more efficient to use the destructive versions of functions in
|Ruby? I know that in Lisp/Scheme destructive counterparts are usually
|offered for efficiency reasons.
|
|Can I assume that string.gsub! is preferable to string.gsub when I
|know that the side-effect won't be affecting any other code?

Although most (not all) of bang methods are more efficient than their
counterparts, I discourage the use of them unless the performance is
really problem. "Premature optimization is the source of all evil".

matz.

"Yukihiro Matsumoto" <> schrieb im Newsbeitrag
news: tlab.jp...
> Hi
>
> In message "Re: destructive! operations"
> on Sun, 20 Feb 2005 17:22:34 +0900, Navindra Umanee
> <> writes:
>
> |Is it more efficient to use the destructive versions of functions in
> |Ruby? I know that in Lisp/Scheme destructive counterparts are usually
> |offered for efficiency reasons.
> |
> |Can I assume that string.gsub! is preferable to string.gsub when I
> |know that the side-effect won't be affecting any other code?
>
> Although most (not all) of bang methods are more efficient than their
> counterparts, I discourage the use of them unless the performance is
> really problem. "Premature optimization is the source of all evil".

Although I agree to the latter statement, I beg to differ on the general
remark - at least a bit. I often use this

while ( line = gets )
line.chomp!
# work with line
end

because I know it's going to be potentially invoked often - even in scripts
that are likely to run only on small input files. But for large files where
not every line is processed it easily divides the number of instances
created by a factor of 2.

Kind regards

robert

Robert Klemme, 20/2/2005 12:04:
> "Yukihiro Matsumoto" <> schrieb im Newsbeitrag
> news: tlab.jp...
>> In message "Re: destructive! operations"
>> on Sun, 20 Feb 2005 17:22:34 +0900, Navindra Umanee
>> <> writes:
>>
>> |Is it more efficient to use the destructive versions of functions in
>> |Ruby? I know that in Lisp/Scheme destructive counterparts are usually
>> |offered for efficiency reasons.
>> |
>> |Can I assume that string.gsub! is preferable to string.gsub when I
>> |know that the side-effect won't be affecting any other code?
>>
>> Although most (not all) of bang methods are more efficient than their
>> counterparts, I discourage the use of them unless the performance is
>> really problem. "Premature optimization is the source of all evil".
>
>
> Although I agree to the latter statement, I beg to differ on the general
> remark - at least a bit. I often use this
>
> while ( line = gets )
> line.chomp!
> # work with line
> end
>
> because I know it's going to be potentially invoked often - even in
> scripts that are likely to run only on small input files. But for large
> files where not every line is processed it easily divides the number of
> instances created by a factor of 2.

Bad example:

while ( line = gets.chomp )
# work with line
end

On Feb 20, 2005, at 5:23 PM, Caio Tiago Oliveira wrote:
> Bad example:
>
> while ( line = gets.chomp )
> # work with line
> end

unless ruby cow's the string and
the copy just has a truncating length,
then this requires copying of the line.

Alex

On Feb 20, 2005, at 10:23 AM, Caio Tiago Oliveira wrote:

> Bad example:
>
> while ( line = gets.chomp )
> # work with line
> end

gets() returns a String or nil. nil does not support chomp(). When
the chomp() is inside the while loop, this isn't an issue.

James Edward Gray II

James Edward Gray II <> wrote:
> > Bad example:
> >
> > while ( line = gets.chomp )
> > # work with line
> > end
>
> gets() returns a String or nil. nil does not support chomp(). When
> the chomp() is inside the while loop, this isn't an issue.

Often think it would be nice if "" and 0 were treated like nil. Such
functions could then return "". Heck, NilClass.to_s and NilClass.to_i
already return "" and 0 respectively.

Matz talks about premature optimizations. It looks like nil was made
this way for efficiency purposes! Can't say if it was premature
though.

Thanks for the answers!

Cheers,
Navin.

Navindra Umanee <> wrote:
> Often think it would be nice if "" and 0 were treated like nil. Such
> functions could then return "". Heck, NilClass.to_s and NilClass.to_i
> already return "" and 0 respectively.

"false" too..

Incidentally I tried to make "", 0 and false respond positively to
nil?. While they did, none of the boolean tests looked at nil? to
make their decision. I guess that's the optimized part.

Cheers,
Navin.

Navindra Umanee wrote:
> James Edward Gray II <> wrote:
>
>>>Bad example:
>>>
>>>while ( line = gets.chomp )
>>> # work with line
>>>end
>>
>>gets() returns a String or nil. nil does not support chomp(). When
>>the chomp() is inside the while loop, this isn't an issue.
>
>
> Often think it would be nice if "" and 0 were treated like nil. Such
> functions could then return "".

One problem with this suggestion that comes to mind is, what if there
are any blank lines in the file. then gets.chomp would return "" which
would cause the while loop to exit. Probably not what you want

--
Mark Sparshatt

mark sparshatt <> wrote:
> One problem with this suggestion that comes to mind is, what if there
> are any blank lines in the file. then gets.chomp would return "" which
> would cause the while loop to exit. Probably not what you want

Point. The chomp would make it not work here. There are many
situations where it could be elegant though.

Cheers,
Navin.