861.18 KB, text/html
104.52 KB, text/plain
118.71 KB, text/plain
1.62 KB, text/plain
easier said than done really...this bug is useless without a reason as to why it takes so long.
can someone run quantify?
I could try, but I don't know when I'll get the time to do that.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → mozilla1.0
OK, I just tried running "time" on Moz and Netscape both as they open and HTML file with the script, open all the windows, and then quit. Results: Netscape: 8.06user 0.85system 0:21.86elapsed 40%CPU Mozilla: 137.88user 0.52system 2:47.84elapsed 82%CPU Going to try profiling Moz....
Looks like most of the time opening windows is spent constructing the frames for the chrome and also executing some JS (or in something that is called from JS). Hyatt, could you have a look at the attached quantify data and see if there's some low hanging fruit there? Seeing nsXULElement::SetAttribute() at 16% and also nsWindow::OnPaint() at 16% seems a bit weird to me but I haven't looked any closer at this yet, PresShell::AttributeChanged() is alos up there at 13% (this is probably a huge part of the time spent in nsXULElement::SetAttribute()). I'm not pointing fingers, I'm just pointing out what I caught when looking at the data for about 30 seconds.
OS: Linux → All
Hardware: PC → All
Oh, and the data I attached is only what goes on on the main thread, all other threads are ignored in the data.
thanks for doing this jst! This ought to give all of us something to look at. One thing we should probably do next is see how much JS really needs to be executed...
Cc'ing waterson. Is it easy to get F only as well as F+D times (F is function or self, right? D is descendents)? I ask because I doubt much time is being spent in the JS interpreter. Rather, time seems to be spent in natives called from js_Interpret (and/or from js_Invoke). /be
I'll attach a new file that includes the F only column tomorrow when I get back to the office, I doubt JS itself is to blame for much here but I don't have the numbers handy now so I can't say for sure...
I doubt the JS engine itself is slow, but we have a lot of js these days in navigator.js and friends... it wouldn't surprise me if that was slowing us down
I just attached the same quantify data that also contains the F time column (F time is the 4th column, I forgot to type in the headers), looking at that it shows that we spend a whopping 6.8ms in js_Interpret :-) so JS itself is not to be blamed here. Here's the first part of the data sorted on the F time column: F+D % F+D time F time calls Function name 11.73 590564.56 478374.15 134573 new 12.35 621612.37 468081.79 138252 malloc 4.34 218202.55 218202.55 708 LineTo 5.16 259682.14 202216.58 67325 free 3.72 186998.29 157542.71 61638 delete 2.65 133270.28 133270.28 2521 BitBlt 2.16 108632.78 108632.78 1116 StretchDIBits 1.81 91148.59 91148.59 196596 TlsGetValue 1.50 75258.29 75258.29 111521 memcpy 1.48 74724.90 74724.90 432 InvalidateRect 1.44 72424.96 72424.96 737 GetClipRgn 1.43 71944.68 71944.68 102045 strlen 1.37 68796.59 68796.59 37511 memmove 1.23 61709.66 61709.66 564 GetDC 1.53 77096.20 60557.52 2469776 FindEndOfWeight 1.19 59652.23 59652.23 822640 AccumulateCRC 1.06 53382.43 53382.43 83839 memset 1.02 51331.04 51331.04 564 ReleaseDC 1.02 51155.27 49411.29 362 SystemParametersInfoA 16.43 827113.99 46978.95 46145 nsSupportsArray::EnumerateForwards 1.22 61305.97 46080.01 692 PeekMessageA 0.90 45404.96 45404.96 3560 js_FlushPropertyCacheByProp 2.24 112486.80 41314.83 260 SetWindowPos 0.78 39179.61 39179.61 485 GetMessagePos 0.69 34919.00 34917.34 2388 DeleteObject 0.64 32451.43 32417.75 114031 nsDST::SearchTree 1.69 85043.48 29936.60 164382 nsXULElement::GetAttribute 0.58 29347.13 29347.13 112 SetPropW 0.57 28823.69 28823.69 69043 ftol 0.53 26643.96 26643.96 260 StretchBlt 0.56 28320.76 25116.48 4248 realloc 0.50 24994.89 23931.20 64 CreateWindowExA 3.32 167192.64 23773.92 1540832 nsCOMPtr_base::~nsCOMPtr_base 0.47 23409.92 23409.92 103173 nsCharTraits<WORD>::move 0.42 21195.28 21195.28 506 GetMessageTime 0.41 20822.66 20822.66 83534 LeaveCriticalSection 0.75 37738.08 20084.94 100007 Compare
Whaaaaaa!!!! That didn't come out right, way to go NS6! I'll attach the data from the last comment, sorry about that.
I'm feeling like Bipolar Man today, up and impervious one minute, down and over-sensitive the next! js_FlushPropertyCacheByProp is sticking out, asking for JS blame. I've filed bug 68735 on that. /be
This seems strongly related to bug 49141; I'll be charitable and mark this bug as dependant rather than a dup since we have such nice data in this bug (and it's not exactly the same bug, although I think that the root causes are quite likely to be identical).
Depends on: 49141
I'll defend brendan. Are you quoting F time, or F+D time? (I suspect the latter, see news://news.mozilla.org/3A8AF290.446AA622@netscape.com for another analysis of window.open().) I discovered that JS *doesn't* take that much time for window.open(), but the native routines that JS calls *do* take a lot of time. We built the browser out of JS and XUL, so a lot of the time spent opening a new browser window is going to be thunking through JS at some point.
*** Bug 100210 has been marked as a duplicate of this bug. ***
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
Removing unneeded qawanted keyword; if you disagree please add it back and state what you want from QA.
Mass-reassigning bugs to firstname.lastname@example.org
Assignee: jst → dom_bugs
Assignee: general → nobody
QA Contact: desale → general
window.open() is pretty fast with a nightly build on a modern system. Does anyone still thinks that window.open() performance is a big problem ?
Status: NEW → RESOLVED
Last Resolved: 10 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.