Hi all,
I am trying to profile the JavaScript bit of an extension I maintain. Is there any recommended method similar to wfProfileIn/Out in MediaWiki? How do you do profiling on ResourceLoader?
Cheers, Markus
On Tue, Jan 31, 2012 at 2:18 PM, Markus Glaser glaser@hallowelt.biz wrote:
Hi all,
I am trying to profile the JavaScript bit of an extension I maintain. Is there any recommended method similar to wfProfileIn/Out in MediaWiki? How do you do profiling on ResourceLoader?
There is no MediaWiki-side support for JS profiling. However, most JS debugging tools in browsers provide function-level JS profiling. I know for a fact that Firebug (a Firefox extension that provides a JS debugger and console) does.
Roan
On Tue, Jan 31, 2012 at 8:38 AM, Roan Kattouw roan.kattouw@gmail.com wrote:
On Tue, Jan 31, 2012 at 2:18 PM, Markus Glaser glaser@hallowelt.biz wrote:
Hi all,
I am trying to profile the JavaScript bit of an extension I maintain. Is there any recommended method similar to wfProfileIn/Out in MediaWiki? How do you do profiling on ResourceLoader?
There is no MediaWiki-side support for JS profiling. However, most JS debugging tools in browsers provide function-level JS profiling. I know for a fact that Firebug (a Firefox extension that provides a JS debugger and console) does.
The developer tools built into Chrome also have this feature.
-Chad
Thanks a lot for your answers. I wanted to make sure there's no "official MW way". Now I know :)
Cheers, Markus
-----Ursprüngliche Nachricht----- Von: wikitech-l-bounces@lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] Im Auftrag von Chad Gesendet: Dienstag, 31. Januar 2012 14:52 An: Wikimedia developers Betreff: Re: [Wikitech-l] JavaScript profiling
On Tue, Jan 31, 2012 at 8:38 AM, Roan Kattouw roan.kattouw@gmail.com wrote:
On Tue, Jan 31, 2012 at 2:18 PM, Markus Glaser glaser@hallowelt.biz wrote:
Hi all,
I am trying to profile the JavaScript bit of an extension I maintain. Is there any recommended method similar to wfProfileIn/Out in MediaWiki? How do you do profiling on ResourceLoader?
There is no MediaWiki-side support for JS profiling. However, most JS debugging tools in browsers provide function-level JS profiling. I know for a fact that Firebug (a Firefox extension that provides a JS debugger and console) does.
The developer tools built into Chrome also have this feature.
-Chad
_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
*Cough* some random article about making js that is not abusing the slower parts of the language http://www.bcherry.net/talks/js-better-faster *Cough*
On Tue, 31 Jan 2012 08:36:02 -0800, Tei oscar.vives@gmail.com wrote:
*Cough* some random article about making js that is not abusing the slower parts of the language http://www.bcherry.net/talks/js-better-faster *Cough*
Bah, that frankly looks worthless.
It goes all over extremely micro optimizations. The kind of thing that'll have almost no effect and even less effect as JS engines get better. And sticking obsessively to that kind of coding inevitably ends up to horridly hard to read and manage code. We should be advocating good readable coding style over micro-optimizations for performance. Some of the examples even look broken. And the way he uses $("<div/>") in a loop. You'd think that someone obsessed with performance would forgo re-running jQuery's "Is this some html or a query" checks and dom creation and just use .clone().
And to top it off, it doesn't even bother pointing out .delegate over .live. Something that could actually have an effect in improving page performance. I hate .live, it binds the event to the body instead of binding it only as far out as it needs to go, and even does it after doing a worthless dom query. And as a result things bound with .live end up having piles of worthless dom events executed just to be exited by jQuery. THAT does affect performance when you have hundreds of dom events that don't need to fire.
On Tue, Jan 31, 2012 at 6:09 PM, Daniel Friesen lists@nadir-seen-fire.com wrote:
On Tue, 31 Jan 2012 08:36:02 -0800, Tei oscar.vives@gmail.com wrote:
*Cough* some random article about making js that is not abusing the slower parts of the language http://www.bcherry.net/talks/js-better-faster *Cough*
Bah, that frankly looks worthless.
Additionally, while putting your script tags at the bottom of the body is better than putting them in the head, making them load asynchronously from the head (HeadJS-style) is even better. This is also what ResourceLoader uses in 1.19 if you enable an experimental config variable.
Roan
On 31 January 2012 18:09, Daniel Friesen lists@nadir-seen-fire.com wrote:
On Tue, 31 Jan 2012 08:36:02 -0800, Tei oscar.vives@gmail.com wrote:
*Cough* some random article about making js that is not abusing the slower parts of the language http://www.bcherry.net/talks/js-better-faster *Cough*
Bah, that frankly looks worthless.
It goes all over extremely micro optimizations. The kind of thing that'll have almost no effect and even less effect as JS engines get better.
This is wishfull thinking. I mostly agree.
*remembers something* Opera seems working on a profiler for CSS. Chrome seems working in that too. It will be supersweet to press F12 in Chrome and see what are the slowest selectors / most expensive rendering things. Maybe discover that border radious is the most expensive, about 4 times more than opacity (??).
wikitech-l@lists.wikimedia.org