Optimization Tips

Jim

I've always thought for used each under the hood.

http://blog.grayproductions.net/articles/the_evils_of_the_for_loop

for loops do not have their own scope - the loop variable and any variables created in the loop become available (or are over-written) in the current scope.

With .each, variables are local to the block {..}

thomthom

@jim said:

I've always thought for used each under the hood.

http://blog.grayproductions.net/articles/the_evils_of_the_for_loop

for loops do not have their own scope - the loop variable and any variables created in the loop become available (or are over-written) in the current scope.

If you click the method names in the Ruby API manual you get to see the sourcecode:
http://ruby-doc.org/core/classes/Array.html#M002173

Jim

That's showing a for loop in the c language.

thomthom

That's what it's doing under the hood.

Jim

@thomthom said:

That's what it's doing under the hood.

Right, so where is the definition for the for function?

The answer is there isn't one because for is not a function, but is "sugar". The for loop in Ruby really uses the .each method behind the scenes.

Although, I can't recall where I learned that. The link to the blog article mentions it, though.

tbd

speaking of each vs for :

loop1 = []
loop2 = []

calls = ["one", "two", "three"]

calls.each do |c|
  loop1 << Proc.new { puts c }
end

for c in calls
  loop2 << Proc.new { puts c }
end

loop1[1].call #=> "two"
loop2[1].call #=> "three"

Dan Rathbun

@jim said:

The for loop in Ruby really uses the .each method behind the scenes. ... Although, I can't recall where I learned that.

'Pick-Axe' > For ... In expressions

Jim

I guess to get back on topic, for loops are not faster then .each iterators. The performance must have to do with how the for loop variables are not loop scoped, as in each.

thomthom

Came across this link:
http://www.h3rald.com/articles/efficient-ruby-code-shortcut-review/

On that list it says
@unknownuser said:

Use parallel assignment (a, b = 5, 6) where applicable

while at this link:
http://www.hxa.name/articles/content/ruby-speed-guide_hxa7241_2007.html

@unknownuser said:

Avoid parallel assignment

thomthom

@thomthom said:

Came across this link:
http://www.h3rald.com/articles/efficient-ruby-code-shortcut-review/

On that list it says
@unknownuser said:

Use parallel assignment (a, b = 5, 6) where applicable

while at this link:
http://www.hxa.name/articles/content/ruby-speed-guide_hxa7241_2007.html

@unknownuser said:

Avoid parallel assignment

I just bought the ebook and that review summary was wrong - parallel assignments are not recommended for performance important tasks.
Interesting read that book btw.

MartinRinehart

Let's see - for performance I'm going to avoid iterations, arrays, hashes and objects.

What's left?

thomthom

@martinrinehart said:

What's left?

puts "Hello World"

AdamB

@jim said:

I guess to get back on topic, for loops are not faster then .each iterators. The performance must have to do with how the for loop variables are not loop scoped, as in each.

"Your racing car is not faster than my Trabant, it just covers more ground in a shorter time than my car."

cjthompson

Has anyone looked into Enumerable.grep()? it seems pretty useful, but I don't know how fast it is.

Jim

@adamb said:

@jim said:

I guess to get back on topic, for loops are not faster then .each iterators. The performance must have to do with how the for loop variables are not loop scoped, as in each.

"Your racing car is not faster than my Trabant, it just covers more ground in a shorter time than my car."

Heh? Oh. Yes, I see.

Would it be correct to say: An each loop can be as fast as a for loop if the loop variable has been initialized?

thomthom

That would mean it's not the each loop itself that's slow - but the creation of variables.

Jim

Exactly.

thomthom

Vertex.position is slow! Cache the result if you need to use the same Point3d multiple times.

Point3d.distance also accepts Vertex objects in place of Point3d or Array.
point1.distance(vertex2) is faster than point1.distance(vertex2.position).

Sketchup Vertex.position speed performance - ThomThom's Website

(www.thomthom.net)

AdamB

Its all interesting info you're digging up thomthom, but I wonder where you're going..

Ruby is a scripting language that makes for very quick development, modern constructs and good readability. So you pay for that with execution performance. However, performance with a big P which may include how fast you can complete and deliver functionality may be better - but once again I do think you should play to Ruby's strength rather than perhaps bend it into something it isn't.

By the time you've created local copies of state, rewritten everything using a compact form etc etc you end up with something that is less readable and probably more prone to bugs. And as you've discovered, there is a massive difference in performance between native code and Ruby - such a large gulf, you're never going to come even close to closing it.

You should do heavy lifting with a C extension and GUI / API / semantic stuff with Ruby. Processing geometry topology with Ruby is, in general, not practical. Not that it can't be done..but that's not what I'm suggesting.

thomthom

@adamb said:

Its all interesting info you're digging up thomthom, but I wonder where you're going..

That was actually stuff I found out before I got around to do a C extension.
Jumping from Ruby - or any other scripting language - C extensions is not an easy jump. If C isn't your cup of tea then it's worth knowing what saves time in Ruby. Most plugin writers here doesn't do C and have no interest in it either. Just making something that work - but still one can save noticeable time.

What I found most interesting in those test was that Vertex is a valid argument where the manual claims only Point3d. And passing the Vertex is faster than Vertex.position.

As for C extensions - it appear that there's a significant overhead of converting VALUEs to workable C types - so if you iterate only once over a set of data there isn't much to gain. Only if there's quite a bit more calculations.