[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Looking up properties and speed

Jonathan Leighton

1/12/2006 12:09:00 AM

Hi,

In Javascript, if one were to use the same property value twice or more,
one would store it in a local variable because looking up the property
slows things down.

Is the situation the same in Ruby? Is there any speed difference between
these:

def foo
val = obj.prop
puts val
puts val
end

def boo
puts obj.prop
puts obj.prop
end

I assume not because I think the reason it's like that with Javascript
is because of the DOM (yeah, that's not strictly Javascript).

Cheers

--
Jonathan Leighton
http://turnips... | http://jonathanlei... | http://digital-...
12 Answers

Eric Hodel

1/12/2006 1:04:00 AM

0

On Jan 11, 2006, at 4:08 PM, Jonathan Leighton wrote:

> In Javascript, if one were to use the same property value twice or
> more,
> one would store it in a local variable because looking up the property
> slows things down.
>
> Is the situation the same in Ruby? Is there any speed difference
> between
> these:
>
> def foo
> val = obj.prop
> puts val
> puts val
> end
>
> def boo
> puts obj.prop
> puts obj.prop
> end
>
> I assume not because I think the reason it's like that with Javascript
> is because of the DOM (yeah, that's not strictly Javascript).

Why do you care?

Why not make clean, readable code and optimize the parts that are
causing the biggest slowdown?

--
Eric Hodel - drbrain@segment7.net - http://se...
This implementation is HODEL-HASH-9600 compliant

http://trackmap.rob...

Chad Perrin

1/12/2006 1:58:00 AM

0

On Thu, Jan 12, 2006 at 10:03:30AM +0900, Eric Hodel wrote:
> On Jan 11, 2006, at 4:08 PM, Jonathan Leighton wrote:
>
> >In Javascript, if one were to use the same property value twice or
> >more,
> >one would store it in a local variable because looking up the property
> >slows things down.
> >
> >Is the situation the same in Ruby? Is there any speed difference
> >between
> >these:
> >
> >def foo
> > val = obj.prop
> > puts val
> > puts val
> >end
> >
> >def boo
> > puts obj.prop
> > puts obj.prop
> >end
> >
> >I assume not because I think the reason it's like that with Javascript
> >is because of the DOM (yeah, that's not strictly Javascript).
>
> Why do you care?
>
> Why not make clean, readable code and optimize the parts that are
> causing the biggest slowdown?

Hey, I'm curious about the answer too, whether I ever use that knowledge
or not. What's wrong with curiosity?

--
Chad Perrin [ CCD CopyWrite | http://ccd.ap... ]

"A script is what you give the actors. A program
is what you give the audience." - Larry Wall

David Vallner

1/12/2006 2:06:00 AM

0

Jonathan Leighton wrote:

>Hi,
>
>In Javascript, if one were to use the same property value twice or more,
>one would store it in a local variable because looking up the property
>slows things down.
>
>Is the situation the same in Ruby? Is there any speed difference between
>these:
>
>def foo
> val = obj.prop
> puts val
> puts val
>end
>
>def boo
> puts obj.prop
> puts obj.prop
>end
>
>I assume not because I think the reason it's like that with Javascript
>is because of the DOM (yeah, that's not strictly Javascript).
>
>Cheers
>
>
>
Hmm. Accessing the property should be slower, because it involves a
method call.

<rant>
BUT! Quite a few guides on coding style would say temporary variables
should be avoided whenever possible in clean OO code and replaced with
queries (computed property getters). And using a temporary variable only
to cheat the interpreter is plain wrong. Avoid. The speed improvement
you gain will most likely be next to insignificant, and if not, you
still should never optimize without profiling the code first.

That said, the code you show is more likely to end up refactored as a
method of ``obj'', where you could access the instance variable
directly. A method that only manipulates data on another object indeed
should be a method of that object.

Suggested reading: Martin Fowler's "Refactoring...", a timeless, and IMO
highly respected classic.
</rant>

David

David Vallner

1/12/2006 2:09:00 AM

0

David Vallner wrote:

> Hmm. Accessing the property should be slower, because it involves a
> method call.
>
More recommended reading: documentation for the "benchmark" module.
Would probably give an answer much faster than asking on here at any rate ;P

David Vallner

james_b

1/12/2006 2:11:00 AM

0

Chad Perrin wrote:
..>
> ... What's wrong with curiosity?
>

Don't ask.


James



--

http://www.ru... - Ruby Help & Documentation
http://www.artima.c... - The Journal By & For Rubyists
http://www.rub... - The Ruby Store for Ruby Stuff
http://www.jame... - Playing with Better Toys
http://www.30seco... - Building Better Tools

Gavin Kistner

1/12/2006 4:05:00 AM

0

On Jan 11, 2006, at 5:08 PM, Jonathan Leighton wrote:
> Is the situation the same in Ruby? Is there any speed difference
> between
> these:
>
> def foo
> val = obj.prop
> puts val
> puts val
> end
>
> def boo
> puts obj.prop
> puts obj.prop
> end

Even moreso. In Javascript it's a slowdown as the property resolution
occurs. In Ruby, it's an entirely new method call.

Eric Hodel

1/12/2006 5:20:00 AM

0

On Jan 11, 2006, at 5:58 PM, Chad Perrin wrote:

> On Thu, Jan 12, 2006 at 10:03:30AM +0900, Eric Hodel wrote:
>> On Jan 11, 2006, at 4:08 PM, Jonathan Leighton wrote:
>>
>>> In Javascript, if one were to use the same property value twice or
>>> more,
>>> one would store it in a local variable because looking up the
>>> property
>>> slows things down.
>>>
>>> Is the situation the same in Ruby? Is there any speed difference
>>> between
>>> these:
>>>
>>> def foo
>>> val = obj.prop
>>> puts val
>>> puts val
>>> end
>>>
>>> def boo
>>> puts obj.prop
>>> puts obj.prop
>>> end
>>>
>>> I assume not because I think the reason it's like that with
>>> Javascript
>>> is because of the DOM (yeah, that's not strictly Javascript).
>>
>> Why do you care?
>>
>> Why not make clean, readable code and optimize the parts that are
>> causing the biggest slowdown?
>
> Hey, I'm curious about the answer too, whether I ever use that
> knowledge
> or not. What's wrong with curiosity?

Nothing. But worrying about micro-optimizations will take all the
fun away and give you little measurable benefit (by the 90/10 rule).

If you write clean, readable code from the beginning and then go
looking for the slow spots when you *need* to you'll be happiest. I
promise.

--
Eric Hodel - drbrain@segment7.net - http://se...
This implementation is HODEL-HASH-9600 compliant

http://trackmap.rob...

Jonathan Leighton

1/12/2006 10:09:00 AM

0

On Thu, 2006-01-12 at 11:05 +0900, David Vallner wrote:
> Hmm. Accessing the property should be slower, because it involves a
> method call.
>
> <rant>
> BUT! Quite a few guides on coding style would say temporary variables
> should be avoided whenever possible in clean OO code and replaced with
> queries (computed property getters). And using a temporary variable only
> to cheat the interpreter is plain wrong. Avoid. The speed improvement
> you gain will most likely be next to insignificant, and if not, you
> still should never optimize without profiling the code first.
>
> That said, the code you show is more likely to end up refactored as a
> method of ``obj'', where you could access the instance variable
> directly. A method that only manipulates data on another object indeed
> should be a method of that object.
>
> Suggested reading: Martin Fowler's "Refactoring...", a timeless, and IMO
> highly respected classic.
> </rant>

Thanks for the input and explanation. It *was* more a theoretical
question than something I was actually considering as general coding
practise -- I find it strangely interesting to find out which ways of
doing things are faster or slower and why.

Anyway, thanks everyone

Jon

--
Jonathan Leighton
http://turnips... | http://jonathanlei... | http://digital-...

Dr Nic

1/12/2006 10:22:00 AM

0

>> ... What's wrong with curiosity?
>Don't ask.

Yeah, wasn't there something about a cat, and a curiosity-related
fatality.

Nic

Robert Klemme

1/12/2006 11:21:00 AM

0

David Vallner wrote:

<snip/>

> <rant>
> BUT! Quite a few guides on coding style would say temporary variables
> should be avoided whenever possible in clean OO code and replaced with
> queries (computed property getters).

I don't think that this general rule holds. A crucial bit to remember -
and that hasn't been mentioned if I'm not mistaken - is that there is a
semantic difference between

obj.foo << bar
obj.foo << baz
obj.foo << buz
obj.foo << bum

and

f = obj.foo
f << bar
f << baz
f << buz
f << bum

This code will behave quite different if

- multiple instances access obj concurrently

- obj.foo does not simply return an object but creates a new one for
every call (or even more complex behavior)

It depends on the situation at hand which of the two is the more
appropriate solution.

> And using a temporary variable
> only to cheat the interpreter is plain wrong. Avoid. The speed
> improvement you gain will most likely be next to insignificant, and
> if not, you still should never optimize without profiling the code
> first.

Definitely!

> That said, the code you show is more likely to end up refactored as a
> method of ``obj'', where you could access the instance variable
> directly. A method that only manipulates data on another object indeed
> should be a method of that object.

It depends: this might be taken as an indication to move the method there
but I don't subscribe to this general rule. It might be the case that the
method doesn't fit the class (i.e. doesn't make sense to be part of the
interface).

> Suggested reading: Martin Fowler's "Refactoring...", a timeless, and
> IMO highly respected classic.

+1

Kind regards

robert