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
On Jan 11, 2006, at 4:08 PM, Jonathan L. wrote:
val = obj.prop
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 H. - [email protected] - http://segment7.net
This implementation is HODEL-HASH-9600 compliant
On Thu, Jan 12, 2006 at 10:03:30AM +0900, Eric H. wrote:
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 P. [ CCD CopyWrite | http://ccd.apotheon.org ]
“A script is what you give the actors. A program
is what you give the audience.” - Larry Wall
David V. 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 
David V.
Jonathan L. wrote:
val = obj.prop
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.
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 F.'s “Refactoring…”, a timeless, and IMO
highly respected classic.
David
Chad P. wrote:
…>
… What’s wrong with curiosity?
Don’t ask.
James
–
http://www.ruby-doc.org - Ruby Help & Documentation
Ruby Code & Style - The Journal By & For Rubyists
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys
http://www.30secondrule.com - Building Better Tools
On Jan 11, 2006, at 5:08 PM, Jonathan L. wrote:
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.
On Thu, 2006-01-12 at 11:05 +0900, David V. wrote:
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 F.'s “Refactoring…”, a timeless, and IMO
highly respected classic.
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
On Jan 11, 2006, at 5:58 PM, Chad P. wrote:
between
puts obj.propHey, 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 H. - [email protected] - http://segment7.net
This implementation is HODEL-HASH-9600 compliant
… What’s wrong with curiosity?
Don’t ask.
Yeah, wasn’t there something about a cat, and a curiosity-related
fatality.
Nic
David V. wrote:
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 F.'s “Refactoring…”, a timeless, and
IMO highly respected classic.
+1
Kind regards
robertJonathan L. wrote:
val = obj.prop
is because of the DOM (yeah, that’s not strictly Javascript).Cheers
Accessing a property involves a function call, which is probably slower
than caching the value in a local variable. Even more so if the
computation of the property value is expensive. However, I would worry
about the speed difference only when the coding path is an application
hot spot.
– stefan
[Sidetracking gruesomely]
In which case, making #foo look like a property accessor is probably
misleading, naming the method #make_foo or #create_foo is probably
better
style.
David V.
On 1/11/06, Jonathan L. [email protected] 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?
In almost any language method calls will be slower than directly
accessing a variable. I did a quick benchmark with my “quickbench”
utility (I’ll release it one of these days), and here are the results:
| QuickBench Session Started |
| 3000000 Iterations |
|---|
user system total real
| Fastest was <2. var == other_var> |
|---|
So the method call it about half as fast, which isn’t that bad. Here
is the code:
require ‘quickbench’
class Test
attr_reader :foo
def initialize(foo)
@foo = foo
end
end
test = Test.new(‘something’)
val = test.foo
other_val = ‘blah’
QuickBench.go(3000000, 25) {}
END
test.foo == other_val
val == other_val
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs