Call for attention - context handlers and validation procs

[thomthom]

I hope the various scripters here can take a moment and look into this.

While working on a large siteplan where I had ~200-300K edges I noticed that when I had selected everything and right-clicked SU would freeze up for several seconds before poping up the window. Often the SU window would flicker as it returned to a responsive state and cause the right click menu to disappear.

I tried with all plugins disabled and found that there was then no lag at all.

It occurred to me that some plugins might be trying to process the whole selection in the context handler. Checking my own plugin I found Selection Toys to do so - which of course is a naught thing to do. I modified it so it'd only inspect the selection if the selection was less than 1000 entities. When the selection is over 1000 it makes the assumption that the selection can contain anything and display all menus.

That cut down the lag a little, but there's still many seconds lag. So there is more plugins. Initial scan of my plugins I found no more, so now I ask the rest of you to review your context menu handlers.

And I expect one should be just as careful when it comes to validation procs. (I'm a wee bit unsure to exactly when these triggers - as toolbar buttons also can have these.)

Summary:
Don't process the whole selection in context handlers or validation procs. Place size limitations or remove the validation all together.

Test the right click menu and it's performance on large models with large selections when adding context handlers.

---

Debug Script for Benchmarking

#tt_context_handler.rb

Open the Ruby Console, when right-clicking performance data will be outputted.

To list all attached handlers:
TT.list_context_handlers

[tbd]

maybe we should create a checklist for releasing ruby scripts, something like http://lite.launchlist.net

[thomthom]

I think that would be a good idea.

[AdamB]

I'm half finished with a plugin called "Snitch" which collates the time each plugin's Observers take so we can start pointing fingers.

Guidelines are fine, but witchhunts / naming and shaming has much better results.

[thomthom]

How do you manage to track other observers?
Can it be translated into validation procs and context handlers?

[Chris Fullmer]

Guidelines are fine, but witchhunts / naming and shaming has much better results.

Woohoo!, let the games begin. I have a feeling I'm gonna score big!!!! (I hope its good to score big )

[thomthom]

[honoluludesktop]

Are the witches hunting, or are we hunting witches?-)

Don't know what the following has to do with this topic, but it seemed like the thing to do:-)

[thomthom]

uh... both maybe

[honoluludesktop]

That's rich! The opening scene strikes a cord, it's me writing an app:-)

temp00.jpg

[thomthom]

I made a little sniffer script that will log the scripts that creates context handlers. Lets one easier inspect which scripts are adding context handlers.

I found xLine to be processing the whole selection. I'll be looking further into what scripts have inefficient context handlers. At the moment it takes many seconds for me when I right click a large set of selected entities.

(Removed - See first post)

Type TT.list_context_handlers to get a list of attached context handlers in the Ruby Console.

[thomthom]

I just updated the first post with the debug script - it now benchmarks the handlers, outputting the time they take to process to the Ruby Console.

[thomthom]

Sample output for a selection of about 100K entities:

### Context Handler ###
2D#loader.rb:181:in `activate' [...] 2D#.rb:44
0.0 seconds

### Context Handler ###
bezier.rb:501 [...] bezier.rb:501
0.006 seconds

### Context Handler ###
parametric.rb:320 [...] (eval):2696
0.0 seconds

### Context Handler ###
(eval):103:in `load' [...] pb_loader.rb:9
0.0 seconds

### Context Handler ###
tt_bitmap2mesh.rb:29 [...] tt_proxy_loader.rb:28
0.0 seconds

### Context Handler ###
tt_image_opacity.rb:30 [...] tt_proxy_loader.rb:28
0.0 seconds

### Context Handler ###
ui_manager.rb:261:in `build_ui' [...] tt_selection_toys.rb:240
0.004 seconds

### Context Handler ###
xLine.rb:51 [...] xLine.rb:51
0.0 seconds

### Context Handler ###
Lib6Plugin.rb:656:in `build_config_handlers' [...] ZLoader__FredoScale.rb:24
0.0 seconds

### Context Handler ###
Lib6Plugin.rb:656:in `build_config_handlers' [...] ZLoader__OnSurface.rb:26
0.489 seconds

### Context Handler ###
(eval):299:in `initialize' [...] dynamiccomponents.rb:38
0.0 seconds

### Context Handler ###
webtextures_loader.rb:886 [...] webtextures.rb:22
0.0 seconds

### Context Handler ###
bezierspline_main.rb:2413:in `load_all_menus' [...] extensions.rb:36:in `load'
5.657 seconds

(Note I had modified xLine and Selection Toys prior to this test)

[fredo6]

Sample output for a selection of about 100K entities:

### Context Handler ###
bezierspline_main.rb:2413:in `load_all_menus' [...] extensions.rb:36:in `load'
5.657 seconds[/ruby]

I fixed the one for BezierSpline, with an upgrade.
see http://forums.sketchucation.com/viewtopic.php?f=323&t=13563&p=100509#p100509

Fredo

[thomthom]

[Pout]

Reminds me of something simular I seem to have in big models when rightclicking a material.
The rightclick window just doesn't pop-up

[thomthom]

Reminds me of something simular I seem to have in big models when rightclicking a material.
The rightclick window just doesn't pop-up

Yea - I've noticed that too. Very annoying. But that menu isn't accessible to ruby plugins. So I think that one is on Google's shoulders.

[Jim]

Sample output for a selection of about 100K entities:

### Context Handler ###
bezierspline_main.rb:2413:in `load_all_menus' [...] extensions.rb:36:in `load'
5.657 seconds[/ruby]

I fixed the one for BezierSpline, with an upgrade.
see http://forums.sketchucation.com/viewtopic.php?f=323&t=13563&p=100509#p100509

Fredo

Bezierspline_main is still sort-of slow for me - it takes 8 seconds for the context menu to pop-up for 75,000 selected entities. (I admit to having a sub-standard pc.)

[fredo6]

Bezierspline_main is still sort-of slow for me - it takes 8 seconds for the context menu to pop-up for 75,000 selected entities. (I admit to having a sub-standard pc.)

Jim,

I made a change in the script.
see main post on BezierSpline

Is is better with this release

Thanks

Fredo

[thomthom]

[mitcorb]

Are you saying that each and every plugin is "polled" each time you wish to do something whether you "invoke" that/those plugins or not? If so, is that efficient? Keep in mind I don't know the terminology, and I certainly don't fully understand.

[thomthom]

Are you saying that each and every plugin is "polled" each time you wish to do something whether you "invoke" that/those plugins or not? If so, is that efficient? Keep in mind I don't know the terminology, and I certainly don't fully understand.

Not every plugin, but when a plugin want to add a context menu a function is run - and if the plugin tried to evaluate the whole selection or do any processor expensive calculations in this function it'll delay the context menu.

[mitcorb]

Ok, that makes some sense, thanks. Evidently, the context menu is lower in priority?

[Dan Rathbun]

not really... the context menu is "built on the fly"...

The menu needs to know what items and submenus it will need to display. It cannot know what they will be until Sketchup processes all the context_menu_handlers.