Last modified: 2013-12-06 22:11:18 UTC
Created attachment 14004 [details] CPU-20131206T162413.cpuprofile Inspired by the report at https://www.wikidata.org/wiki/Wikidata:Project_chat#Firefox_freezes_opening_an_item_in_a_new_tab I used Google Chrome to generate a CPU profile on this page: https://www.wikidata.org/wiki/Q212?debug=1 The browser cache was emptied before testing and the page took ~4 minutes to finish loading. I saved the profile and uploaded as an attachment (you can inspect it after loading it into Google Chrome).
Created attachment 14005 [details] Flame Chart
Created attachment 14006 [details] CPU time by function
This is caused by two problems, one of which is somewhat easy to fix when you know what to look for (see below), and the other not so much. The second problem is, obviously, the fact that *there's just so much code*, and executing more code usually takes more time. I think even loading VE requires less. Seriously, this is mad. The first is that elements are sometimes first inserted into DOM, and then "filled" with their children. This causes continuous reflows and repaints when executing the script. The 81.82% "idle" time in Helder's log is spent on reflows, repains and other related browser activities. The worst offender here seems to be jquery.wikibase.entityview, which does `$( '<div/>' ).appendTo( this.element ).claimgrouplistview( { … } )` – where the .claimgrouplistview() call generates the entire list of claims that spans several screens of text. If you scroll down during the loading of the page, you can see the claims being built part-by-part in real time. The obvious fix – changing the order of operations – seems to cause all of the edit links not to appear (unless I borked something else). I did not investigate the root cause, probably something somewhere ten levels of abstraction deep calls .parent()/.closest(), which at that point returns an empty collection due to the element being parentless. Somebody more knowledgeable about the code will probably be able to track this down easily.
*** This bug has been marked as a duplicate of bug 54098 ***
