HTMLDialog callbacks

Developers Ruby API
1

I noticed today that the new way of sending callbacks is significantly slower when passing a large json object. Does anyone know why?

vs this: (both tested on HTML dialog even though this method isn’t documented for HTMLDialog class.)

t1 = performance.now()
sketchup.save_openings(Openings);
t2 = performance.now()
console.log(t2-t1)
>> 228.46999999997206

t1 = performance.now()
window.location = 'skp:save_openings@' + JSON.stringify(Openings);
t2 = performance.now()
console.log(t2-t1)
>> 16.809999999939464
2

What is the result units ? seconds? milliseconds?

3

Milliseconds.

4

Okay, so it’s the difference between a blink of an eye and 7.5% of a blink. :wink:

It is interesting however.

What is the time if you do …

t1 = performance.now()
sketchup.save_openings(JSON.stringify(Openings));
t2 = performance.now()
console.log(t2-t1)

… and on the Rubyside …

dialog.add_action_callback('save_openings') {|_unused, openings|
  @my_hash[:openings]= JSON.parse(openings)
  # ... etc., ...
}
5

As I understand it, calls to Ruby from UI::HtmlDialog are asynchronous.
So testing linear durations like this might not be meaningful.

@tt_su ?

6

Interesting…

t1 = performance.now()
sketchup.save_openings(JSON.stringify(Openings));
t2 = performance.now()
console.log(t2-t1)
>> 22.330000000001746

t1 = performance.now()
sketchup.save_openings(Openings);
t2 = performance.now()
console.log(t2-t1)
>> 244.33000000000175
7

Have you tried multiple iterations and finding the min, max and mean ?

8

I ran them both half a dozen times and the times are pretty consistent ±10%.

That’s actually what started the investigation. I hate unnecessary lag in any app, and 200ms is usually about where I start to notice (and investigate) lag.

In the meantime I’ve changed the code to only send information about the items that changed instead of sending the whole thing. It’s interesting thought that stringifying is that much faster.

Looks now like I wouldn’t have needed to. Interesting knowledge to store in the back of my mind. At least I now know the sketchup.method_name is not the culprit.

t1 = performance.now()
sketchup.save_openings(JSON.stringify(Openings));
t2 = performance.now()
console.log(t2-t1)
>> 9.390000000130385

t = Time.now
openings = JSON.parse(openings) if openings
puts "#{Time.now - t} seconds to parse openings json."
>> "0.029919 seconds to parse openings json."
9

Actually I think it is. The reason I had you explicitly do the JS side JSON.stringify is to bypass (to a certain extent) the JS sketchup object’s argument processing and just give it a plain String, which has always been passed on over to Ruby without change.

The nifty built-in JS Object --> Ruby Hash process seems to be implemented in a not so efficient way.

10

We’ll need some input from Trimble on that. @thomthom

sketchup.save_openings
< function save_openings() { [native code] }
11

Hm… that’s interesting. I’m not entirely familiar with the exact nature of the logic involved in passing data from CEF to the app. But the performance difference is certainly worth an investigation.

Do you mind logging an issue in the tracker? GitHub - SketchUp/api-issue-tracker: Public issue tracker for the SketchUp and LayOut's APIs

12
13

I use some javascript and some jquery. My HTML is essentially embedded and it doesn’t load from disk. I have a huge amount of data in cabmaker.

471 language translations for 537 labels (prompts)
413 dynamic drop downs
464 text boxes
130 check boxes
All in 9 tabs

These are all loaded and then captions, text boxes, check boxes and drop downs are all resized (different languages require different amount of room.

I ran web dialogs against html dialogs (5 times each) and then took an average

Web Dialog
0.151 seconds to load data (with my own methods)
2.55 seconds to resize forms and to trigger Ready function.

HTML Dialog
0.126 seconds to load data (with my own methods)
0.433 seconds to resize forms and to trigger Ready function.

Clients can choose old and new browser as a configuration setting. I run the same code for both versions with a very small part that is version specific.

With the first few versions on htmldialog I was not impressed

but now and needless to say I am quite impressed with the html dialog.

14

So my findings are that the htmldialog is significantly faster than webdialog
I use a strategy similar to the old Token ring network. So - even though it is asynchronous - it goes back and forth until done and you don’t loose any timing.

Sorry - I should mention that my desktop computer is 7 years old.