Script processing time with increasing number of entities


Hi there! I been reading all around about running ruby scripts on SketchUp (SU2017 in my case) but, ultimately, I have found no solution to one last problem I have so I come here to ask all the gurus from whom I have learned so far.

I have some huge code that loads different objects (as components), transforms and mixes them up creating some random virtual environment defined by some simple parameters, e.g., given house layout and dimensions it could generate a complete house model with furniture, wall textures and such.

However, process time does not seem to escalate linearly with (following the previous example) rooms. Say, if I want to generate a room with random furniture and textures it would take from 1 to 10 seconds but if I want 2 rooms it just does not take twice the time (consider there is no interaction between rooms, i.e., they are generated independently).

As far as I have seen, If I add/create more entities in a single script the time and memory usage needed to complete the full process explodes (SketchUp does not slow down my computer, just uses more and more of my hard drive). I could always just run a code that creates a room, wait, run again to create another, wait, etc, but I’m guessing its not the idea, I may just be doing something wrong.

I just recently tried embedding the script inside a start_operation/commit_operation but it still takes too long for the amount of entities I want to handle at the same time. Is there a better/cleve/magical way to generate a huge model like this or is this proper/expected behavior?

Thanks in advance for any insight, solution or help provided!


Compare the running time with the outliner window open and closed, it can make a big difference.


Are you setting the disable ui flag on the operation? That can make a big difference too.

Edit: some more thoughts

  • what extensions do you have installed? Possibly an extension is inefficient in handling your growing model. Some lurk in the background monitoring what you or your code does.
  • review your code and make sure your algorithm is linear not combinatoric with model complexity


#move! is much faster than #transform!

timing the creation and transformation of 100 new groups 10 times

#move! #transform! #move!+#view_refresh
0.309829 4.967845 1.654401
0.713421 5.623649 1.668133
1.252844 6.322374 1.742637
1.82146 7.128948 2.18597
2.300832 7.91556 2.76977
2.77691 9.32414 3.230112
3.299536 9.738511 3.766372
3.942887 10.533348 4.374677
4.464373 11.454798 4.944771
5.05191 12.485585 5.59878

I tend to use #view_refresh on every item as it slows SU very little after 500 and gives you something to watch…



Thanks for all your suggestions!

You’re right, I tested it and having the Outliner window open does considerably reduce performance. Adding entities does not only takes around 10 times the usual time but also escalates way more per entity added. Sadly, I didn’t have the Outliner open in the first place.

Yes, I’m disabling the UI on the operation as I read form Dan Rathbun in another post. I’m not sure though if it is better to embed all my code in a single operation or apply one start/commit per atomic entity placing/handling.

Primarly VRay to set some special textures. Besides that just some ThomThom’s tools/utilities/libraries. I deleted a one or two others that I wasn’t using and, as you said, performance improved. The time escalating factor of the process reduced to around 60%, so it is still not linear but closer. I tried disabling the remaining extensions (TT’s and VRay’s) but I found no improvement.

Checked again twice, I’m almost sure the only interaction between a new entity and the rest of the model is when I add it to the model.entities (which may be as little as using entities.add_group or entities.add_instance and just once per object).

I haven’t been able to test this since .move! apparently does not transform the entity in place I wasn’t able to try it out by just replacing .transform! by .move! on the code. However, I wasn’t aware of the view.refresh method and it has been really helpful to visualize how the process slows down after a while.

Just to give some more details. You can assume the code just adds some entities by loading the components or drawing the required faces (depending on the object) inside a .each loop for the desired number of elements. Adding a single element takes about 0.2s at first (on the computer I’m working on) but then more than 10 or 30 times when model size increases.


It’s hard to give concrete advise without having some code to look at.

As a generic advice, one very common performance issue I observe is using .typename instead of .is_a? for type checking.


It could be the issue with not giving your components unique names.


Thanks Neil! You are totally right about this issue of component naming, but it is only a problem when you make instances unique, as you do on your example code. So, in the end, I couldn’t improve much more my script’s process time.

However, you gave me good insight on how SketchUp handles some processes. For example, just by testing I found out that adding a set of faces (e.g. 3D text) directly on the active model’s entities is way slower than adding them on a group and then exploding the group (at least for a large amount of entities, i.e. > 1000), although I’m not sure why. Probably because drawing the entities costs much more than changing their parent.


Did active_entities have existing geometry? Adding entities in SketchUp gets increasingly more expensive the more geometry is in the target entities collection. This is because SketchUp geometry is expected to merge and deduplicate.

Bulk operations will be faster than a series of single-entity operations. For instance, entities.fill_from_mesh is much faster than a loop of entities.add_face. selection.add(array_of_entities) is much faster than array_of_entities.each { |e| selection.add(e).


Thanks Thom! Your word is rule. It’s great to finally be sure about the correct/intended behavior so I can code with that on my mind.

To answer you, if anyone else is reading this, my active_entities did have existing geometry and, just as you said, I experienced more process time when increasingly adding entities than when adding them in bulk.