Optimization Tips

thomthom

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)

TIG

@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) ?

Whaat

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.

thomthom

@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 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.

thomthom

@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 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.

TIG

@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 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)

Dan Rathbun

$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.)

Whaat

thanks Dan. That will come in handy!

AdamB

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.

thomthom

@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.

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 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

@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.

thomthom

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 ruby for loop?

AdamB

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.

thomthom

@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 the code tag for block codes. (Though I wish there was a way to expand it - I loathe internal scrollbars.)

thomthom

Interesting test Adam:

doit 6.474 3.292 nil

Note: I increased the number of iterations ( 10000000.times { ... })

thomthom

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

AdamB

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.

thomthom

Agree - whitespace eating of ruby has bothered me as well. Will ask if it can be changed.

AdamB

@thomthom said:

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.

thomthom

Is that why each is slow?