I have a lot of boolean operations going on during the creation of the roof primitive. I think the tool suspends the redraw until the very end whereas when it is not running within the tool it is trying to do a bunch of redraws which just take up processing cycles but don’t actually display to the screen and are needlessly causing the CPU crunch and delay.
I saw a note that for v2018 there was a fix for explode could take a long time. You only see this on v2017 right?
I remember the reports on group.explode slowness and something about it happening only at the model root. But can’t find them now.
Another thing that can take time and memory is recursive method calls. Using any of those?
1 Like
Found the problem.
I had this:
@model0.start_operation(@plugin_operation)
When I should have this:
@model0.start_operation(@plugin_operation, true)
The difference is like night and day. This is a major win for me since I’ve noticed in my other plugins (to a much lesser extent) this same sort of behavior. I will need to carefully go through all my plugins and fix this problem with each of my start operation calls. It’s in the documentation but somehow I missed it I guess.
The disable_ui flag should really default to true not false.
For some reason when the start operation is called for an operation within a tool it must suppress the redraw or set the disable_ui flag to true.
2 Likes
Ah … ha! I was onto that …
But I didn’t think you wouldn’t have known about the disable_ui flag.
I briefly considered asking, but then thought “naw… everyone has learned to use that by now.” 
I also thought so when the 2nd arg was first added. But there is code out there that wants to allow the user to see things as they are drawn, so the principle of backward compatibility wins out.
From within a tool, I think you need to invalidate the view to queue up the view for a redraw.
1 Like
I guess I should have seen this a long time ago but somehow it got passed me. I’ve now updated every singe occurrence in all my plugins. Dramatic performance improvement all around.
Previously I chalked the problem up to using an older version of SU (2015 thru 2017) but apparently that was not the case. I then thought maybe it was just my installation, too many extensions installed or my computer was getting old.
You learn something new every day. I’ve been beat up for a few years now with this one, at least I’ve finally solved it.
1 Like
Why do you suspect that affects performance?
That’s a good thing to do with big objects. It’s easy to end up with objects which refer to themselves in a loop which prevents GC from cleaning up. (Though I’ve not seen that be a performance issue… Mainly something I’ve been aware of to be a good citizen of the environment my extensions are hosted in.)
Ideally yes. But it has side-effects and it wasn’t there when the API was first introduced. So the default false is there for compatibility.
By the way, rubocop-sketchup will warn about this:
See this repo for example VSCode project that uses it:
Additionally, while it’s still a work in progress, you could try SpeedUp:
It’s a wrapper around RubyProf for use within SketchUp. Really helpful to pin-point bottlenecks.
2 Likes
Thank-you for the links. I think I could make good us of those tools on some of my more complex modules.
Is Ruby’s GC not smart enough to handle detached circular references?
Not sure… and I think the answer might depend on Ruby version. I see work on the GC system at every release.