Speed and definitions

We have made a large plugin that produces smart windowframes in SU.
We work with large projects that can result in multiple buildings, all with multiple windowframes. Each windowframe consists of multiple components and definitions.
When i work on larger projects, the number of definitions can grow large, into the 10.000s or more.
Many unused definitions keep lingering untill i perform a Purge. Due to speed issues on bigger models i dont want to call a purge from my code if its not strictly needed.

When i redraw 1 windowframe, it normally takes up to a few seconds max, but in models with a high number of definitions, this same process can take very long, upto minutes even.

I realise my own code plays a big part, but i have the suspicion that adding new definitions to an already large definitionlist can get real slow. When i redraw and it takes longer, a purge does speed up the process tremendously.

Can anyone give me some insights on how this process works, if im correct in my suspicion that larger definitionlists slows down actions noticably (like adding new definitions) and if there are any tips how to approach issues like this to move towards a solution?

Thanks in advance for any responses

There have been some speed improvements done in some recent releases. Are you still running v 2018 as your profile states ?

Well since SU2018 we now have Sketchup::DefinitionList#remove() that allows us to delete a single definition if our code knows that this component will no longer be used, instead of brute force purging the whole collection.

So your code could try to keep the list concise by removing unused definitions as soon as they are unneeded.

A definition that is up for removal might also contain the only instances of other definitions which might make them eligible for removal as well. So basically the removal code would be a recursive loop that collects nested definition references for removal.
But you need to check a definition that it is unused using #count_used_instances or count_instances to see if they are still used before removing.
Note that you can still remove a used definition and ALL of it’s instances will be deleted.

But also, one major thing that can slow down your processes is having the Component inspector open, set to the “In Model” collection and showing thumbnails images. Also having the Outliner open has been known to slow down SketchUp as well. (I always run with the Outliner in it’s own TREE tray auto-hidden into the left margin so it doesn’t need to be updated until it slides into view upon a mouseover of it’s margin tab. Similarly I never have the Component inspector set to show thumbnails unless I’m using to find components to insert etc. When done I always switch it back to the name listing.)

There have also been reports (maybe @gkernan ) that when there are such massive numbers of objects groups are faster to add via the Ruby API.

Yes … if your subcomponents will never be manually placed by users, then they should likely be groups instead, as group definitions do not appear in the Component browser for the “In Model” collection. (Not sure but they may not have embedded thumbnail images that bloats filesize and would need to be updated when changes occur.)

I think Gerry’s conclusion what that the component system does an inefficient search to make sure the name is unique, and the search time grows faster than linear as the number of components increases. Groups automatically get the next sequence number for their name (e.g. “Group#21”) regardless of how many already exist. That removes any concern about uniqueness, though it may leave gaps in the numbering sequence if groups have been deleted.


Oh yea. That tickles my memory. The name search time is an open issue right?

So far as I know…

I am running SU2021 and i always keep my outliner closed.
The application adds all definitions using the Ruby API
I was researching the option to remove definitions directly when they become obsolete.
Also im not 100% sure the problem is the number of definitions, but removing all unrelated definitions from my model, speeds things up a lot. I will do some tests removing definitions from the list myself the moment they become obsolete and i will transform some into groups.

Thanks for the replies. Any additional ideas are always welcome

1 Like

Aye. Particularly affecting groups because get all default their name to Group#.