@gkernan
In this post, you said that using ‘Windows 10 with Nvidia’, you found HtmlDialogs to be four times slower than WebDialogs when checked with SU2017 thru SU2019.
Just wondering, what was the begin/end of your timing metric?
I just checked an HtmlDialog, and:
-
From proceeding the #show call to SU Ruby receiving the '‘DOMContentLoaded’" callback was about 15 ms.
-
I got performance.now() at the top of the <script> in the html, and showed an alert when the execute_script (with all the initial values) was received and processed, time was oddly consistent, around 37 ms.
Personally, I’m not bothered by ~ 60 ms for dialog to show.
What were you finding?
I’m pushing a huge amount of data over to the html dialog.
Lots of drop downs etc.
So over 2 seconds is a problem. 1/2 a second I can live with
Garry,
That’s a lot of code. I assume you’ve determined if HtmlDialog#execute_script has a length limit. I don’t know if it does.
-
Are you loading the ‘empty’ html then sending the values via execute_script?
-
Is all html set via #set_html or #set_url, or are you loading ‘tabs’ on demand?
-
Any idea how much time is used in show/show_modal to DOMContentLoaded, vs DOMContentLoaded to the last #execute_script statement?
-
Any idea how many execute_script statements are needed to load it?
I might be able to help, but I don’t know how your Ruby/CEF communication is set up. Below is a grab of dialogs I’m using to work on a generic HtmlDialog interface. With the interface, some dialogs have no js, all that’s needed is added by the framework. One piles a bunch of ‘dialog commands’ with various ‘set’ methods, then sends them with one ‘send_script’ method.
JFYI, the material/layer tables work with keyboard navigation. With layers, up/down scroll, right sets visible, and left set active. Fun like that… But, nothing like the number of controls you have…
It was a while ago, but I wrestled with large DOM issues with https://msp-greg.github.io, as the AWS docs have around 68k methods…
There is even more going on - I have a translation system where I translate prompts, titles, mouse over hints etc. I also resize and reposition things under the hood since different translation requires more or less space. French takes more space than English.
I do load an empty form for all of the tabs up front. There are lots of inter dependencies between parameters. There are 435 translations.
To get around size limitations I send the data to the form in 8 large chunks. Html Dialog does have a size limitation (can’t remember the exact size). I kinow that with web dialog I could have sent fewer chunks. Since my code works with both Html and web I don’t worry about that. So I send the first chunk and process it on the dialog side and once finished I send a request back to ruby to send the next chunk, ruby side receives the request and sends the next chunk. This back and forth continues until all chunks are processed. I do not have any timers slowing things down.
After this is accomplished I trigger cascading changes which essentially enables the proper controls and prompts.
I am on a 6 year old desktop. I’m happy running a slower machine since it immediately shows where I need to improve code performance.
The user can switch between html dialogs and web dialogs and choose the one they want. If they are running older Sketchup then their choice is ignored and in that case I use web dialog.
Control counts:
Drop Downs - 141
Check Boxes - 114
Text Boxes - 401
titles - 66
labels - 448
buttons - 24
Total controls - 1194
1 Like
Here are some timings showing the difference between Html dialog and Web dialog.
The amount of data passed is 25031 bytes
|
|
|
|
Averages |
| SU 2019 |
Html Dialog |
Pass 1 |
0.578 |
|
|
|
Pass 2 |
0.553 |
0.565 |
|
|
|
|
|
|
Web Dialog |
Pass 1 |
2.065 |
|
|
|
Pass 2 |
2.024 |
2.045 |
|
|
|
|
|
| SU 2018 |
Html Dialog |
Pass 1 |
0.728 |
|
|
|
Pass 2 |
0.656 |
0.692 |
|
|
|
|
|
|
Web Dialog |
Pass 1 |
2.104 |
|
|
|
Pass 2 |
2.136 |
2.120 |
|
|
|
|
|
| SU 2017 |
Html Dialog |
Pass 1 |
0.737 |
|
|
|
Pass 2 |
0.616 |
0.676 |
|
|
|
|
|
|
Web Dialog |
Pass 1 |
2.064 |
|
|
|
Pass 2 |
2.077 |
2.071 |
1 Like
Garry,
You’ve mentioned that:
- All the html is passed with either
set_html or set_url.
- “I also resize and reposition things under the hood’. Don’t know if this done via something like ‘cssRules’ or using individual element styles.
Have you worked much with the Chrome ‘Performance Recorder’ (CPR)? What would be really informative is if you could capture the page load. I know if you reload a visible HtmlDialog with set_html, CPR will record what you need to see.
I suspect that if you’re re-styling a large DOM tree, CEF is taking a lot of time rendering.
It’s a little hard to tell how Chrome renders large documents, but I’ve got a web page that’s 466k, querySelectorAll('*').length is 12.6k, and it loads (via XHR) in a bit over 700 ms.
OFF-TOPIC: I’m not a Chrome/CEF expert, although at one point (years ago) I worked with it a great deal. The only way I know to open ‘dev tools’ in CEF is via a right mouse click, then “Show DevTools”. Then one can start the recorder from the ‘Performance’ tab. Then, one needs to reload the HtmlDialog box, which I suspect for many plugin/extensions, is not a normal operation…
My gui code includes preparing data to be sent to html dialog and processing data coming back. It is 341 KB in size. Additionally there is JQuery and css
I’m actually pretty happy with it as it loads on average in 565 miliseconds.
I see no need at this point in trying to optimize it further. Since WebDialog is being dropped - I’m not going to worry about it.
I figured that it was rather involved…
I hadn’t heard that. Any more info, or anyone from Trimble/SketchUp care to comment?
cc: @thomthom
Sorry - I’ve got it all backwards. It is webdialog that is being depricated.
Also - all my timings were reversed. It is html dialog that is way faster than webdialog.
1 Like
Ok.
If you have a minute, an update to your post that I linked to at the top of this thread would probably be appreciated, as people could get the wrong impression…
1 Like
Isn’t this indicating the HtmlDialog is faster than WebDialog? The numbers are seconds, right?
Oh, I saw you last comment just now. What are the timings measuring? Total time from calling .show to some event in the dialog?
Yes HtmlDialog is faster than WebDialog.
The timings are in seconds - I just formated the miliseconds coming from Time.now()
Times are from starting to prepare the embedded html until everything is loaded / populated and sized which happens at the end of the document.ready function.
