Multi-part transclusion dialog a little slow to load
Open, NormalPublic8 Story Points

Description

Open the dialog for the 'General Election 2015' table on https://en.wikipedia.org/wiki/Tooting_(UK_Parliament_constituency)?veaction=edit . Observe that it takes several seconds to load (>10s for me).

Improvements were made to this which has lessened the problems significantly, but it could still be improved further.

Esanders created this task.May 9 2016, 9:13 PM
Restricted Application added subscribers: Zppix, Aklapper. · View Herald TranscriptMay 9 2016, 9:13 PM
This comment was removed by Esanders.
This comment was removed by Esanders.

Change 287776 had a related patch set uploaded (by Esanders):
Attach template form after building

https://gerrit.wikimedia.org/r/287776

The above patch speeds the test case up from ~10s to ~4s, so probably still room for improvement.

Jdforrester-WMF set the point value for this task to 1.May 9 2016, 10:51 PM
Jdforrester-WMF triaged this task as High priority.
Jdforrester-WMF added a subscriber: Jdforrester-WMF.

Ouch.

Change 287776 merged by jenkins-bot:
Attach template form after building

https://gerrit.wikimedia.org/r/287776

Like you said in one of the earlier (deleted) comments, yeah, it seems that TextInputWidget#adjustSize is the biggest problem. I don't really have any advice what to do about it.

One thing I noticed is that #adjustSize is often called multiple times, e.g. from ve.ui.MWParameterPage constructor:

	this.valueInput = this.createValueInput()
		.setValue( this.parameter.getValue() )

Constructing the input results in an #adjustSize call later (from #installParentChangeDetector), calling #setValue results in another immediate call (from #onChange). This could be avoided by constructing the inputs with { value: this.parameter.getValue() } in their config, or changing OOjs UI not to call #adjustSize from #onChange if the element is detached, or maybe just debouncing calls to #adjustSize if we can't figure out how to call it less often.


Apart from that, it looks like you're just doing a lot of work here. There are 2180 element nodes inside .ve-ui-mwTemplateDialog. Perhaps some of that could be lazy-loaded?

In fact, it looks like it would be easy to do at least for the "info" and "remove" buttons in ve.ui.MWParameterPage, since they're not shown until the user focusses the field anyway. And PopupButtonWidgets turn out to be a bit expensive when you build 50 of them at once.


Also, some ideas for micro-optimisations:

  • There are a few calls to OO.ui.Element.static.scrollIntoView (from ve.ui.MWTemplateDialog#setPageByName) for detached elements. They should be avoided, or scrollIntoView should be improved to do nothing for detached elements.
  • You construct PopupButtonWidgets in ve.ui.MWParameterPage (this.infoButton) even if they're going to be disabled and never have any popup. A plain ButtonWidget would do.
  • $foo.html( mw.message( 'bar' ).parse() ) is an anti-pattern, this causes the message to be parsed to DOM, serialized to HTML string, then parsed from the HTML string again. I noticed one in ve.ui.MWTemplatePage constructor. It's better to do $foo.msg( 'bar' ) (we extend $.fn with this function in jqueryMsg), or $foo.append( mw.message( 'bar' ).parseDom() ).
  • We use $element.closest( 'html' ).length in TextInputWidget to check if the widget is detached, maybe we should use jQuery.contains( document.documentElement, $element[0] ) or something?

I don't really have time to work on this, but do ping me with patches to review. :)

Jdforrester-WMF changed the point value for this task from 1 to 8.

This is now taking <2s, although this is a smallish table so scale that up to a longer one and it's worth keeping this open.

Change 328380 had a related patch set uploaded (by Bartosz Dziewoński):
ve.ui.MWParameterPage: Restructure constructor to reduce needless work

https://gerrit.wikimedia.org/r/328380

matmarex added a comment.EditedDec 20 2016, 3:32 PM

With the test case from the other task (https://nl.wikipedia.org/wiki/Lijst_van_rijksmonumenten_in_Zaandam?veaction=edit) this is still pretty terrible. The dialog takes ~10 seconds to open, and the hundreds of MutationObservers from TextInputWidgets firing afterwards make it unusable for several more seconds after it has opened. The dialog itself is also very choppy, there's some weird stuff going on when you scroll.

The above is my last patch about this for now, this isn't terribly pressing. For whoever looks here next, I suggest lazy-loading things and somehow magicking away the MutationObservers.

Change 328380 merged by jenkins-bot:
ve.ui.MWParameterPage: Restructure constructor to reduce needless work

https://gerrit.wikimedia.org/r/328380

Deskana renamed this task from Multi-part transclusion dialog very slow to load to Multi-part transclusion dialog a little slow to load.Oct 11 2017, 9:38 PM
Deskana lowered the priority of this task from High to Normal.
Deskana updated the task description. (Show Details)
Deskana moved this task from TR0: Interrupt to Backlog on the VisualEditor board.

The example I provided, https://nl.wikipedia.org/wiki/Lijst_van_rijksmonumenten_in_Zaandam?veaction=edit still takes ages, and in firefox, I get the unresponsive script popup. So for these lists it is still far from working. And Zaandam is even a relative short list.

The example I provided, https://nl.wikipedia.org/wiki/Lijst_van_rijksmonumenten_in_Zaandam?veaction=edit still takes ages, and in firefox, I get the unresponsive script popup. So for these lists it is still far from working.

Indeed, it takes ages for me too. This is why the task remains open, and why I added to the description that "Improvements were made to this which has lessened the problems significantly, but it could still be improved further."

And Zaandam is even a relative short list.

It's a a 92 row table where each row is a template transclusion with a bunch of different parameters. When I click edit, it causes 2,268 errors to be thrown into my console, as compared to the 38 that are thrown in the example given in the description. Obviously the visual editor should handle this a lot better than it does, but given its structure, that template is not exactly blameless.

For now, I recommend sticking to wikitext when editing that table.

The example I provided, https://nl.wikipedia.org/wiki/Lijst_van_rijksmonumenten_in_Zaandam?veaction=edit still takes ages, and in firefox, I get the unresponsive script popup. So for these lists it is still far from working.

Indeed, it takes ages for me too. This is why the task remains open, and why I added to the description that "Improvements were made to this which has lessened the problems significantly, but it could still be improved further."

Ok, that is what I want to stress.

And Zaandam is even a relative short list.

It's a a 92 row table where each row is a template transclusion with a bunch of different parameters. When I click edit, it causes 2,268 errors to be thrown into my console, as compared to the 38 that are thrown in the example given in the description. Obviously the visual editor should handle this a lot better than it does, but given its structure, that template is not exactly blameless.

What I mean with a relatively short list is that there are also lists with a couple of 100 rows. So to really solve this, just polishing is not enough, it likely needs a different approach.

For now, I recommend sticking to wikitext when editing that table.

Most people will do that, but this happens to be the kind of list that (also due to wiki loves monuments) relatively new users will see, and run into an unresponsive browser. Maybe it is short term better if VE recognize a complex structure like this and gives a popup this is to complex to edit with VE, with an override to still try it.