https://bugzilla.wikimedia.org/show_bug.cgi?id=46306
--- Comment #79 from Ori Livneh <[email protected]> --- (In reply to comment #76) > We should try to figure out why people hate ULS so much that they want to > actively disable it. I think that this is a useful frame (though 'hate' is a bit extreme). There is a marked discrepancy between our (the developer community, broadly defined) understanding of ULS performance and user's reports of their experiences. The explanation that I think is most convincing is this one: - There are still serious performance issues with ULS. - Users can sense that something is wrong, but they don't always have the means to express it in a technically precise way. - Developers want to fix problems, but we're not measuring anything that shows the problems clearly. - The point of reference for input tools and font rendering is the native capabilities implemented in the OS. - Anything implemented in JavaScript and interpreted at page load is going to be several orders of magnitude slower. There is a wide band of performance degradation that leaves you irritated and aware that something is not as it should, but unable to pinpoint the source of irritation. I've been able to identify one example: the language input selection interface. Something is causing the browser to repeatedly recalculate styles while the interface is active, which makes the browser appear sluggish and unresponsive. This is especially noticeable when scrolling. I recorded a short screencast showing how one might go about diagnosing this issue: <http://www.youtube.com/watch?feature=player_detailpage&v=JprXNc9Ei2A> (YouTube; sorry.) I suspect that this is not an isolated issue, and that there's a lot that we need to investigate. If you want to take a stab at the scroll issue, you might find this resource helpful: http://theamazingweb.net/2013/09/10/debugging-and-fixing-janky-scrolling-with-paul-irish/ Please be nice to the Language Engineering team; they put in a lot of work into making ULS excellent in all the aspects that our development infrastructure is good at disclosing. There is a collective engineering responsibility here to get a handle on user-perceived latency and to integrate it into our code review and acceptance testing processes. In our defense the tooling for doing this kind of work is really in its infancy. (That scroll bottleneck detection tool? It's in the dev channel of Chrom{e/ium}; I don't think it's even in beta yet!) -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
