Last modified: 2014-06-01 08:31:58 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 56292 - (uls-diet) Make ULS more lightweight (tracking)
(uls-diet)
Make ULS more lightweight (tracking)
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
UniversalLanguageSelector (Other open bugs)
master
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
: performance, tracking
Depends on: uls-deployment 65988 40874 41542 42157 42371 46306 46744 47075 48532 48533 51102 56346 56433 56509 56796 56856 59958 60304
Blocks: tracking 55683
  Show dependency treegraph
 
Reported: 2013-10-29 03:59 UTC by Isarra
Modified: 2014-06-01 08:31 UTC (History)
19 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Screenshot of mw.loader.inspect() from the English Wikipedia, 2013-10-30 (257.47 KB, image/png)
2013-10-30 13:10 UTC, MZMcBride
Details

Description Isarra 2013-10-29 03:59:34 UTC
For many users, ULS serves no practical purpose. It is also quite large, which can be problematic if you're not on a first-world internet connection (or are in rural US), is occasionally host to somewhat problematic bugs, and generally is not worth the trouble if you're not part of the target audience.

So there should be a way for such people to just turn the thing off, not load it at all, and be happy.

I appreciate that adding an option for this has been been wontfixed, though I don't know why, but even without there being an option in the interface, there SHOULD be support in the extension itself to disable it, regardless of where it actually appears.

There should be a way for users who are truly and consistently inconvenienced by it to actually solve the underlying problem (such as with a hidden preference or cookie), instead of just hiding it. There should also be a way for third-party hosts to add such an option for their users who also fit the target audience, even if they don't necessarily want it on for everyone.

As it is it seems to inconvenience as many people as it helps on wikimedia projects, and isn't very appealing to third-party hosts, either, despite it solving some very real problems facing some of our users as well.
Comment 1 Siebrand Mazeland 2013-10-29 07:21:55 UTC

*** This bug has been marked as a duplicate of bug 46306 ***
Comment 2 MZMcBride 2013-10-29 13:32:30 UTC
According to mw.loader.inspect(), ULS appears to be by far the largest contributor to JavaScript load on <https://en.wikipedia.org/wiki/Main_Page>:

* jquery.uls
* jquery.uls.data
* ext.uls.init
* ext.uls.webfonts.repository
* ext.uls.interface
* ext.uls.languagenames
* ext.uls.ime

And possibly others. This is all for a feature that most users do not use. This is unacceptably large given that the vast majority of users on the English Wikipedia don't use ULS. This is disproportionate resource usage and is a valid bug to address.

I'm re-opening this bug with a focus on making ULS more lightweight and acceptably performant.
Comment 3 Andre Klapper 2013-10-30 09:37:51 UTC
(In reply to comment #2)
> I'm re-opening this bug with a focus on making ULS more lightweight and
> acceptably performant.

As it sohuld be possible for bug reports to define when they are fixed: 
When exactly would ULS be "lightweight enough" and "acceptably performant"? 

Currently I consider this bug report unfixable (and hence INVALID) as requirements are highly subjective and it's impossible to say "and now ULS is performant and lightweight enough so we can close this bug report".
Comment 4 MZMcBride 2013-10-30 13:09:33 UTC
(In reply to comment #3)

This isn't a helpful comment. Please don't leave unhelpful comments.

Nobody is required to justify a bug report's existence to you. If you can't understand the bug, that's a personal problem. Try following the steps laid out in comment 2 (i.e., run mw.loader.inspect() on the English Wikipedia and look at its output).
Comment 5 MZMcBride 2013-10-30 13:10:33 UTC
Created attachment 13629 [details]
Screenshot of mw.loader.inspect() from the English Wikipedia, 2013-10-30
Comment 6 Andre Klapper 2013-10-30 13:35:25 UTC
(In reply to comment #4)
> This isn't a helpful comment.

The way to avoid this is to define when a report can be considered fixed. 
"Make X faster" is an invalid report as everybody can disagree when it's considered fast enough. Instead, "Make X load within Y seconds" has clear criteria.  It's up to requesters to explain and define issues well enough to avoid invalid bug reports, so I disagree with your interpretation.
Comment 7 MZMcBride 2013-10-30 18:05:06 UTC
Lego, Ori, or anyone else who might know: is there a reason that ULS loads anything more than the init script by default? This is what VisualEditor does, as I understand it.
Comment 8 Bartosz Dziewoński 2013-10-30 18:10:11 UTC
(In reply to comment #6)
> (In reply to comment #4)
> > This isn't a helpful comment.
> 
> The way to avoid this is to define when a report can be considered fixed. 
> "Make X faster" is an invalid report as everybody can disagree when it's
> considered fast enough. Instead, "Make X load within Y seconds" has clear
> criteria.

On what hardware? On what connection? Where, geographically? This is not a clear criterium either, and I'd argue that you can't define a "clear" one.
Comment 9 Siebrand Mazeland 2013-11-04 07:33:44 UTC
Removed dependency on bug 56514. It no longer is relevant after Gerrit change #93035.
Comment 10 Nemo 2014-01-21 21:19:34 UTC
So, as far as we know and until corrected the plan still is, per Erik Moeller, bug 56433 comment 22:
> OK, then I'd like to request that the language engineering team implement
> that
> approach for now, unless there are issues we're overlooking. As noted, we can
> attach EventLogging to font activation, and we could potentially also run
> notices or calls-to-action in specific affected wikis. We can figure out in
> the
> next couple weeks if we want to prioritize getting back into a default-on
> state
> for automatic font delivery for some users/languages quickly, or if this
> should
> take a backseat to the language team's other priorities.
> 
> But, considering the significant payload added by automatic font delivery, I
> think that's a reasonable compromise for now. I appreciate the team's efforts
> to improve ULS performance across the board.

https://gerrit.wikimedia.org/r/#/c/108024/ was already merged and is supposed to serve webfonts only when strictly necessary. So, once the way forward is detected, we need another report for what's needed to complete the plan.
Comment 11 Bryce Glover 2014-02-16 16:50:18 UTC
(In reply to MZMcBride from comment #5)
> Created attachment 13629 [details]
> Screenshot of mw.loader.inspect() from the English Wikipedia, 2013-10-30

I just added up how many kilobytes the ULS loader's scripts take up once loaded onto client systems using my Mac's Calculator.app, and it came out to 450.2 KB!!!  This definitely needs to be fixed!
Comment 12 Amir E. Aharoni 2014-02-16 17:41:50 UTC
(In reply to Bryce Glover from comment #11)
> I just added up how many kilobytes the ULS loader's scripts take up once
> loaded onto client systems using my Mac's Calculator.app, and it came out to
> 450.2 KB!!!  This definitely needs to be fixed!

In which conditions did you make this calculation?
Comment 13 Andre Klapper 2014-02-16 19:16:34 UTC
(In reply to Bryce Glover from comment #11)
> I just added up how many kilobytes the ULS loader's scripts take up once
> loaded onto client systems using my Mac's Calculator.app

Such comments are not helpful if you do not provide exact steps to reproduce.
Comment 14 Bryce Glover 2014-02-18 00:21:51 UTC
(In reply to Amir E. Aharoni from comment #12)
> (In reply to Bryce Glover from comment #11)
> > I just added up how many kilobytes the ULS loader's scripts take up once
> > loaded onto client systems using my Mac's Calculator.app, and it came out to
> > 450.2 KB!!!  This definitely needs to be fixed!
> 
> In which conditions did you make this calculation?

Oops; I should have mentioned that I just used my Mac's built-in Calculator.app application to add up all of the script sizes from the right-hand side of the table provided as an attachment by MZMcBride in Comment #5.  I thought that my source would be obvious!  Now that I think about it, though, where exactly did the results provided by that table come from again?
Comment 15 Santhosh Thottingal 2014-02-18 03:51:28 UTC
The table is from the output of mw.loader.inspect(). You can also run it from your developer tools console of your browser.

But the result of that has a few caveats. ULS has to serve a small svg file(cog icon) to UI. See https://github.com/wikimedia/mediawiki-extensions-UniversalLanguageSelector/blob/master/resources/css/ext.uls.interlanguage.css#L1

You can see the svg with 'embed' more than once. Also note that the ResourceLoader module will have css  with the image data embedded. So the RL module have  this repeated svg data at client side, it is an image, so it will have some size. While calculating the module size, the total size is javascript, css and this image data(potentially duplicated) at client side. But what matters is bandwidth usage and in this case you will see a big difference between actual bandwidth usage and the uncompressed RL module size at client side. This is because the module is gzip compressed while serving. Gzip is efficient in compressing the duplicated strings. In short, don't take the output of mw.loader.inspect literally.
Comment 16 Gerrit Notification Bot 2014-02-18 14:34:02 UTC
Change 113957 had a related patch set uploaded by Bartosz Dziewoński:
resources/images: Optimize all SVGs (partially by hand)

https://gerrit.wikimedia.org/r/113957
Comment 17 Gerrit Notification Bot 2014-02-19 08:50:23 UTC
Change 113957 merged by jenkins-bot:
resources/images: Optimize all SVGs (partially by hand)

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

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links