Optimization Tips

Optimization Tips

Postby Whaat » Tue Jan 19, 2010 11:08 pm

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_meshis the next best thing if you have problems with 'fill_from_mesh'. Avoid the add_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)
3

Whaat 
PluginStore Author
PluginStore Author
 

Re: Optimization Tips

Postby thomthom » Wed Jan 20, 2010 9:29 am

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/viewtop ... 80&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 vs fill_from_mesh
http://forums.sketchucation.com/viewtop ... 30#p205479

Testing 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 a Drawingelement. And even then, test that the object really is a Drawingelement 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/viewtop ... 15#p166698

Set and Hash
Whaat wrote:- Use Hashes or Sets instead of Arrays for lookup purposes as they are faster.

Further info: the Set class uses a Hash to index the content.
One thing to note about Hash 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 wrote:- 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/viewtop ... 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
Code: Select all
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 be Point3d 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 the PolygonMesh, for large meshes it does improve your speed.


Edge mid-points
Use edge.bounds.center
viewtopic.php?f=180&t=51063&p=461075#p461075
0
Thomas Thomassen — SketchUp Monkey & Coding addict
List of my plugins and link to the CookieWare fund
User avatar
thomthom 
PluginStore Author
PluginStore Author
 

Re: Optimization Tips

Postby thomthom » Wed Jan 20, 2010 2:58 pm

Selection
This is slow:
Code: Select all
model.entities.each { |e|
  model.selection.add(e) if e.is_a?(Sketchup::Face)
}


This is faster:
Code: Select all
ents = []
model.entities.each { |e|
  ents << e if e.is_a?(Sketchup::Face)
}
model.selection.add(ents)


Can be condensed to:
Code: Select all
ents = model.entities.collect { |e| e.is_a?(Sketchup::Face) }
model.selection.add(ents)
0
Thomas Thomassen — SketchUp Monkey & Coding addict
List of my plugins and link to the CookieWare fund
User avatar
thomthom 
PluginStore Author
PluginStore Author
 

Re: Optimization Tips

Postby TIG » Wed Jan 20, 2010 3:15 pm

thomthom wrote:Selection
This is slow:
Code: Select all
model.entities.each { |e|
  model.selection.add(e)
}


This is faster:
Code: Select all
ents = []
model.entities.each { |e|
  ents << e
}
model.selection.add(ents)

How about model.selection.add(model.entities.to_a) ?
0
TIG
User avatar
TIG 
Global Moderator
 

Re: Optimization Tips

Postby Whaat » Wed Jan 20, 2010 3:33 pm

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 with fill_from_mesh. 3DS format seems like the logical choice.
0

Whaat 
PluginStore Author
PluginStore Author
 

Re: Optimization Tips

Postby thomthom » Wed Jan 20, 2010 3:35 pm

TIG wrote: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 as selection.add accepts any kind of collection object. It even let you feed it nested array of entities without the need to flatten the array.
0
Thomas Thomassen — SketchUp Monkey & Coding addict
List of my plugins and link to the CookieWare fund
User avatar
thomthom 
PluginStore Author
PluginStore Author
 

Re: Optimization Tips

Postby thomthom » Wed Jan 20, 2010 3:36 pm

Whaat wrote: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 with fill_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.
0
Thomas Thomassen — SketchUp Monkey & Coding addict
List of my plugins and link to the CookieWare fund
User avatar
thomthom 
PluginStore Author
PluginStore Author
 

Re: Optimization Tips

Postby TIG » Wed Jan 20, 2010 4:42 pm

thomthom wrote:
TIG wrote: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 as selection.add accepts any kind of collection object. It even let you feed it nested array of entities without the need to flatten 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 like entities.transform(tr,entities.to_a)
0
TIG
User avatar
TIG 
Global Moderator
 

$VERBOSE set to nil

Postby Dan Rathbun » Thu Jan 21, 2010 7:03 am

$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' mode

These settings correspond to ruby start parameter -W with values of 0,1,2 (which would also set $VERBOSE in a standard Ruby Environment.)
0
    I'm not here much anymore. But a PM will fire email notifications.
    User avatar
    Dan Rathbun 
    PluginStore Author
    PluginStore Author
     

    Re: Optimization Tips

    Postby Whaat » Thu Jan 21, 2010 3:22 pm

    thanks Dan. That will come in handy!
    0

    Whaat 
    PluginStore Author
    PluginStore Author
     

    Re: Optimization Tips

    Postby AdamB » Sun Jan 31, 2010 6:13 pm

    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.
    0
    Developer of LightUp Click for website
    User avatar
    AdamB 
    LightUp Support
    LightUp Support
     

    Re: Optimization Tips

    Postby thomthom » Sun Jan 31, 2010 9:32 pm

    AdamB wrote: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

    Interesting. for is faster than each. 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?


    AdamB wrote: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.
    0
    Thomas Thomassen — SketchUp Monkey & Coding addict
    List of my plugins and link to the CookieWare fund
    User avatar
    thomthom 
    PluginStore Author
    PluginStore Author
     

    Re: Optimization Tips

    Postby thomthom » Sun Jan 31, 2010 9:33 pm

    thomthom wrote: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.
    0
    Thomas Thomassen — SketchUp Monkey & Coding addict
    List of my plugins and link to the CookieWare fund
    User avatar
    thomthom 
    PluginStore Author
    PluginStore Author
     

    Re: Optimization Tips

    Postby thomthom » Sun Jan 31, 2010 9:36 pm

    And why is for faster then each?

    Looking at the source code for Array.each:
    Code: Select all
    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 ruby for loop?
    0
    Thomas Thomassen — SketchUp Monkey & Coding addict
    List of my plugins and link to the CookieWare fund
    User avatar
    thomthom 
    PluginStore Author
    PluginStore Author
     

    Re: Optimization Tips

    Postby AdamB » Mon Feb 01, 2010 11:21 am

    Here's another to look out for. There is a (time) cost associated with "creating" a variable, so its often faster to use variables declared outside the scope of the executing block.

    Code: Select all
    def doit
       
            start = Time.now
       10000.times {
          c = 5
          d = 5
          
          e = c + d
       }
       puts Time.now - start
       
       a = 0
       b = 0
       c = 0
       start = Time.now
       10000.times {
          a = 5
          b = 5
          
          c = a + b
       }
       puts Time.now - start

    end
    0
    Last edited by Jim on Sun Jul 24, 2011 2:30 am, edited 2 times in total.
    Reason: added code tags
    Developer of LightUp Click for website
    User avatar
    AdamB 
    LightUp Support
    LightUp Support
     

    Re: Optimization Tips

    Postby AdamB » Mon Feb 01, 2010 11:23 am

    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.
    0
    Developer of LightUp Click for website
    User avatar
    AdamB 
    LightUp Support
    LightUp Support
     

    Re: Optimization Tips

    Postby thomthom » Mon Feb 01, 2010 11:29 am

    AdamB wrote:OT: Any chance the forum administrator of SCF can fix the 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]ruby is meant for inline code. While you got the code tag for block codes. (Though I wish there was a way to expand it - I loathe internal scrollbars.)
    0
    Thomas Thomassen — SketchUp Monkey & Coding addict
    List of my plugins and link to the CookieWare fund
    User avatar
    thomthom 
    PluginStore Author
    PluginStore Author
     

    Re: Optimization Tips

    Postby thomthom » Mon Feb 01, 2010 11:33 am

    Interesting test Adam:

    doit
    6.474
    3.292
    nil


    Note: I increased the number of iterations (10000000.times { ... })
    0
    Thomas Thomassen — SketchUp Monkey & Coding addict
    List of my plugins and link to the CookieWare fund
    User avatar
    thomthom 
    PluginStore Author
    PluginStore Author
     

    Re: Optimization Tips

    Postby thomthom » Mon Feb 01, 2010 11:35 am

    Didn't realise Ruby would recreate the variables for each iteration. I'd thought it'd keep them for the duration of the loop...
    0
    Thomas Thomassen — SketchUp Monkey & Coding addict
    List of my plugins and link to the CookieWare fund
    User avatar
    thomthom 
    PluginStore Author
    PluginStore Author
     

    Re: Optimization Tips

    Postby AdamB » Mon Feb 01, 2010 11:36 am

    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.
    0
    Developer of LightUp Click for website
    User avatar
    AdamB 
    LightUp Support
    LightUp Support
     

    Re: Optimization Tips

    Postby thomthom » Mon Feb 01, 2010 11:38 am

    Agree - whitespace eating of ruby has bothered me as well. Will ask if it can be changed.
    0
    Thomas Thomassen — SketchUp Monkey & Coding addict
    List of my plugins and link to the CookieWare fund
    User avatar
    thomthom 
    PluginStore Author
    PluginStore Author
     

    Re: Optimization Tips

    Postby AdamB » Mon Feb 01, 2010 11:41 am

    thomthom wrote:Didn't realise Ruby would recreate the variables for each iteration. I'd thought it'd keep them for the duration of the loop...


    The closure you create with curly braces is handled as a first class object and passed as an argument to the iterator. This means the scope of any variables you mention inside that block is limited to that block - it must create them each time. :-(
    0
    Developer of LightUp Click for website
    User avatar
    AdamB 
    LightUp Support
    LightUp Support
     

    Re: Optimization Tips

    Postby thomthom » Mon Feb 01, 2010 12:19 pm

    Is that why each is slow?
    0
    Thomas Thomassen — SketchUp Monkey & Coding addict
    List of my plugins and link to the CookieWare fund
    User avatar
    thomthom 
    PluginStore Author
    PluginStore Author
     

    Re: Optimization Tips

    Postby Gaieus » Tue Feb 02, 2010 9:10 am

    Guys, Thom asked if we can do something with these white spaces but I have to say it is most probable that we cannot. I is hard coded somewhere in the php script of the forum software and even if we could tweak that, it would be impossible to keep it through upgrades (which is very due soon anyway).

    Is the code tag not good (apart from that scrolling annoyance)?
    0
    User avatar
    Gaieus 
     

    Re: Optimization Tips

    Postby thomthom » Tue Feb 02, 2010 9:37 am

    It's ok. I just hoped there was a config UI for BBCode tags on the forum. Thought it was normal. The code tag is ok, just figured if it could be changed...

    I don't suppose there are forum plugins that can be installed? having the code block apply syntax highlighting would be a delight for us coders. Such as this:

    http://code.google.com/p/syntaxhighlighter/



    Edit: what version of phpBB does SCF run? I'm looking at this: http://www.phpbb.com/kb/article/adding- ... in-phpbb3/ from this it appear to be that it'd be a matter of setting the HTML replacement for the ruby tag to not collapse white space using CSS.

    Replacement sample something like this:
    <span style="white-space:pre;">{TEXT}</span>
    0
    Thomas Thomassen — SketchUp Monkey & Coding addict
    List of my plugins and link to the CookieWare fund
    User avatar
    thomthom 
    PluginStore Author
    PluginStore Author
     

    Re: Optimization Tips

    Postby Gaieus » Tue Feb 02, 2010 11:02 am

    I can imagine you would like that syntax highlight! I use Notepad++ and know what a difference it is!

    Coen and Tavi should be spoken to about these things.
    0
    User avatar
    Gaieus 
     

    Re: Optimization Tips

    Postby thomthom » Mon Mar 08, 2010 1:25 pm

    AdamB wrote: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

    In regard to this should one init the variables used by for in to speed up things? or is that not needed?

    Would this
    x = 0
    for x in collection
    # ...
    end

    be faster than
    for x in collection
    # ...
    end
    0
    Thomas Thomassen — SketchUp Monkey & Coding addict
    List of my plugins and link to the CookieWare fund
    User avatar
    thomthom 
    PluginStore Author
    PluginStore Author
     

    Re: Optimization Tips

    Postby AdamB » Wed Mar 17, 2010 12:35 pm

    no
    0
    Developer of LightUp Click for website
    User avatar
    AdamB 
    LightUp Support
    LightUp Support
     

    Re: Optimization Tips

    Postby Jim » Wed Mar 17, 2010 2:24 pm

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

    http://blog.grayproductions.net/article ... e_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 {..}
    0
    Hi

    Jim 
    Global Moderator
     

    Re: Optimization Tips

    Postby thomthom » Wed Mar 17, 2010 2:33 pm

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

    http://blog.grayproductions.net/article ... e_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
    0
    Thomas Thomassen — SketchUp Monkey & Coding addict
    List of my plugins and link to the CookieWare fund
    User avatar
    thomthom 
    PluginStore Author
    PluginStore Author
     

    SketchUcation One-Liner Adverts

    by Ad Machine » 5 minutes ago



    Ad Machine 
    Robot
     

    Next


     

    Return to Developers' Forum

    Who is online

    Users browsing this forum: No registered users and 3 guests

    Visit our sponsors: