Optimization Tips
-
Lately, I have been finding (thanks to the great contributors of this forum) many new ways of optimizing my Ruby code for maximum performance. This thread will just focus on pure SketchUp API Ruby, not C extensions or SDK stuff.
Please add your optimization tips in this thread. If you can also add any performance test results, even better!
Let's make this a sticky thread, too.
Here are some recently found tips (credit Thomthom for some of these):
- Use the Set class instead of Array when you want to store unique values (eg. vertices). It is much faster.
- Use Hashes or Sets instead of Arrays for lookup purposes as they are faster.
entities.fill_from_mesh
is the fastest way to add faces into a model.entities.add_faces_from_mesh
is the next best thing if you have problems with 'fill_from_mesh'. Avoid theadd_face
method.- Use the
Sketchup.active_model.start_operation("task",true)
method to boost performance but first check that the user is running SU7 or higher. - Avoid recursive algorithms as they can easily result in bugsplats (I owe you big for this one Thomthom! )
- If the appropriate SketchUp API methods exists, use it! Since it links to C code, it will almost certainly be faster than creating your own. (See methods in the Geom module, Point3D, and Vector3D classes for examples of what I mean)
-
Made sticky.
Good topic Whaat. I've been planning to make a such a thread myself to collect all the tips from the community.To add to your list:
Adding geometry
I made a series of tests in regards to methods to add geometry to the model: http://forums.sketchucation.com/viewtopic.php?f=180&t=23994
I think I have more test data from when I made the Teapot plugin. Very small changes added up to big time savings.
add_faces_from_mesh
vsfill_from_mesh
http://forums.sketchucation.com/viewtopic.php?f=180&t=23994&st=0&sk=t&sd=a&start=30#p205479Testing for types
.typename
is slow! Only ever use it to test for type if you're looking for one of the entity types that isn't defined in Ruby and only reports back as aDrawingelement
. And even then, test that the object really is aDrawingelement
before you use the expensive string comparison of.typename
.if e.class == Sketchup::Drawingelement && e.typename == 'DimensionLinear'
Instead, test the.class
or use.is_a?
or.kind_of?
..is_a?
and.kind_of?
are aliases of the same method.
Test data: http://forums.sketchucation.com/viewtopic.php?f=323&t=19576&st=0&sk=t&sd=a&start=15#p166698Set and Hash
@whaat said:
- Use
Hash
es orSet
s instead ofArray
s for lookup purposes as they are faster.
Further info: the
Set
class uses aHash
to index the content.
One thing to note aboutHash
in Ruby 1.8: when you iterate over the hash content, it will not be returned in the same order you inserted the elements. (I found code for an OrderedHash to address this.)Recursing
@whaat said:
- Avoid recursive algorithms as they can easily result in bugsplats (I owe you big for this one Thomthom! )
Yea - this really had me stomped when I was writing the early version of SelectionToys. I used recursive loops to iterate over connected entities. That quickly leads to thousands of recursions - which quickly fills up the calling stack.
If you ever use recursing - be 100% sure that it will only be recursed a limited amount of times.PolygonMesh.point_index
polygonmesh.point_index(point)
is slow http://forums.sketchucation.com/viewtopic.php?f=180&t=23994&st=0&sk=t&sd=a&start=30#p205488
The lookup seem to be inefficient.Found it faster to build a separate Hash to keep track of it as I added the points for the mesh.
While adding points
point_index = {} p.each { |i| point_index[i] = pm.add_point(i) }
When collecting points to build polygon:
indexes = points.collect { |point| point_index[point] }
What I haven't tried is adding polygons by providing
Point3d
objects directly instead of feeding it indexes. But I did find out that it must bePoint3d
object, you can't use arrays.PolygonMesh.new
If you know the numbers of points or polygons you're adding, use that in the optional arguments when you create thePolygonMesh
, for large meshes it does improve your speed.Edge mid-points
Use [ruby:1h8o2x5y]edge.bounds.center[/ruby:1h8o2x5y]
http://sketchucation.com/forums/viewtopic.php?f=180&t=51063&p=461075#p461075 - Use
-
Selection
This is slow:model.entities.each { |e| model.selection.add(e) if e.is_a?(Sketchup;;Face) }
This is faster:
ents = [] model.entities.each { |e| ents << e if e.is_a?(Sketchup;;Face) } model.selection.add(ents)
Can be condensed to:
ents = model.entities.collect { |e| e.is_a?(Sketchup;;Face) } model.selection.add(ents)
-
@thomthom said:
Selection
This is slow:> model.entities.each { |e| > model.selection.add(e) > } >
This is faster:
> ents = [] > model.entities.each { |e| > ents << e > } > model.selection.add(ents) >
How about
model.selection.add(model.entities.to_a)
? -
I noticed in that thread about adding geometry to the model that someone tried creating the geometry by writing the mesh out to a temporary file format and then importing presumably with the
model.import
method. I'll have to try this and see how it compares withfill_from_mesh
. 3DS format seems like the logical choice. -
@tig said:
How about
model.selection.add(model.entities.to_a)
?I over simplified the example - updated to reflect a purpose.
Sidenote: .
to_a
isn't required asselection.add
accepts any kind of collection object. It even let you feed it nested array of entities without the need toflatten
the array. -
@whaat said:
I noticed in that thread about adding geometry to the model that someone tried creating the geometry by writing the mesh out to a temporary file format and then importing presumably with the
model.import
method. I'll have to try this and see how it compares withfill_from_mesh
. 3DS format seems like the logical choice.I've not tried it. But I got my doubts. Since it seems that it's SU's own processing when adding geometry that causes the slowdown - I'd be surprised if importing geometry suffers from the same slowdowns.
-
@thomthom said:
@tig said:
How about
model.selection.add(model.entities.to_a)
?I over simplified the example - updated to reflect a purpose.
Sidenote: .to_a
isn't required asselection.add
accepts any kind of collection object. It even let you feed it nested array of entities without the need toflatten
the array.I usually
.to_a
my entities, because it stops me falling into trap like modifying the entities whilst referring to them in a loop; or an array is also needed for some other things likeentities.transform(tr,entities.to_a)
-
$VERBOSE controls messages and warnings that get set to STDERR.
Set to nil so SU Ruby doesn't waste time spitting out useless warnings about sloppy code (like "warning: meaningless use of == in nil context") which noone wants to read anyway (when they're doing modelling.) Or my other favorite "warning: parenthesize arguments for future version."
Settings:
$VERBOSE = nil : sets 'Silent' mode
$VERBOSE = false : sets 'Medium' mode (default)
$VERBOSE = true : sets 'Verbose' modeThese settings correspond to ruby start parameter -W with values of 0,1,2 (which would also set $VERBOSE in a standard Ruby Environment.)
-
thanks Dan. That will come in handy!
-
I see a lot of SU scripts using some of the more compact iterators Ruby iterators. So they might read nice, but they're often slower than just simple for-loops.
http://blog.shingara.fr/each-vs-for.html
The other biggie to look out for is operations that involve copying when modifying in place would work just as well. Its slow and it generates lots of garbage.
-
@adamb said:
I see a lot of SU scripts using some of the more compact iterators Ruby iterators. So they might read nice, but they're often slower than just simple for-loops.
Interesting.
for
is faster thaneach
. Butdo ... end
is faster than{ ... }
? I really didn't expect that. And I don't see why. Thought it was just alternative syntax. But they behave differently?@adamb said:
The other biggie to look out for is operations that involve copying when modifying in place would work just as well. Its slow and it generates lots of garbage.
Interesting. I'll have to look through some of my code. I've not thought of that at all.
-
@thomthom said:
But do ... end is faster than { ... } ? I really didn't expect that. And I don't see why. Thought it was just alternative syntax. But they behave differently?
hm.. maybe not. seemed to very very little difference. suppose that's other things affecting the minute differences.
-
And why is for faster then each?
Looking at the source code for
Array.each
:VALUE rb_ary_each(ary) VALUE ary; { long i; for (i=0; i<RARRAY(ary)->len; i++) { rb_yield(RARRAY(ary)->ptr[i]); } return ary; }
It's using for as well, and the whole loop is done in C - so why isn't this C
for
loop faster than a rubyfor
loop? -
OT: Any chance the forum administrator of SCF can fix the [ruby] tag to not remove formatting. Formatting is a big part of understanding code, and while for regular text collapsing whitespace down to a single space might work, for code it does not.
-
@adamb said:
OT: Any chance the forum administrator of SCF can fix the [ruby:38zsi59i]tag to not remove formatting. Formatting is a big part of understanding code, and while for regular text collapsing whitespace down to a single space might work, for code it does not.
I think the
ruby
is meant for inline code. While you got thecode
tag for block codes. (Though I wish there was a way to expand it - I loathe internal scrollbars.) -
Interesting test Adam:
doit 6.474 3.292 nil
Note: I increased the number of iterations (
10000000.times { ... }
) -
Didn't realise Ruby would recreate the variables for each iteration. I'd thought it'd keep them for the duration of the loop...
-
Seems an arbitrary (and wrong) assumption that inline code requires removing whitespace. Why not just leave in what the author wrote rather than trying to second guess? Whatever.
-
Agree - whitespace eating of
ruby
has bothered me as well. Will ask if it can be changed.
Advertisement