Closed
Bug 68002
Opened 24 years ago
Closed 6 years ago
Window.open() in javascript should be faster
Categories
(Core :: DOM: Core & HTML, enhancement)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: colinp, Unassigned)
References
Details
(Keywords: dom0, perf)
Attachments
(4 files)
From Bugzilla Helper:
User-Agent: Mozilla/4.75 [en] (X11; U; Linux 2.2.16 i686)
BuildID: 2001020608
Under N4.75 opening new windows using window.open() (say 50 new windows) takes
FAR less time than under Mozilla - closing too.
Reproducible: Always
Steps to Reproduce:
1. write a testfile.html (see below)
2. run the file under N4.75 - note the time it takes to open
3. close N4 - note the time it takes to close
4. run the file under Mozilla - note the time it takes to open
5. close mozilla - note the time it takes to close
<HTML>
<HEAD>
<script LANGUAGE="JAVASCRIPT">
function startUp()
{
//0 open
window.open();
window.open();
window.open();
window.open();
window.open();
//5 open
window.open();
window.open();
window.open();
window.open();
window.open();
//10 open
window.open();
window.open();
window.open();
window.open();
window.open();
//15 open
window.open();
window.open();
window.open();
window.open();
window.open();
//20 open
window.open();
window.open();
window.open();
window.open();
window.open();
//25 open
window.open();
window.open();
window.open();
window.open();
window.open();
//30 open
window.open();
window.open();
window.open();
window.open();
window.open();
//35 open
window.open();
window.open();
window.open();
window.open();
window.open();
//40 open
window.open();
window.open();
window.open();
window.open();
window.open();
//45 open
window.open();
window.open();
window.open();
window.open();
window.open();
//50 open
}
</script>
</HEAD>
<body ONLOAD="startUp()">
</BODY>
</HTML>
Actual Results: The performance difference between N4 and Mozilla is
remarkable. Navigator can open and close the windows far more quickly than
mozilla.
Expected Results: The speed should be within reason of the old Navigator 4.
(Currently it takes MINUTES longer to open 50 window in Mozilla)
Running Linux 2.2, P3-700, mozilla 2001020608
Netscape 4.75 under the same specs
|
||
Comment 1•24 years ago
|
||
easier said than done really...this bug is useless without a reason as to why it
takes so long.
can someone run quantify?
|
||
Comment 3•24 years ago
|
||
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
|
||
Comment 4•24 years ago
|
||
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....
|
|
||
Comment 5•24 years ago
|
||
|
|
||
Comment 6•24 years ago
|
||
|
|
||
Comment 7•24 years ago
|
||
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
|
|
||
Comment 8•24 years ago
|
||
Oh, and the data I attached is only what goes on on the main thread, all other
threads are ignored in the data.
|
||
Comment 9•24 years ago
|
||
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...
|
||
Comment 10•24 years ago
|
||
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
|
|
||
Comment 11•24 years ago
|
||
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...
|
|
||
Comment 12•24 years ago
|
||
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
|
|
||
Comment 13•24 years ago
|
||
|
|
||
Comment 14•24 years ago
|
||
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
|
|
||
Comment 15•24 years ago
|
||
Whaaaaaa!!!! That didn't come out right, way to go NS6! I'll attach the data
from the last comment, sorry about that.
|
|
||
Comment 16•24 years ago
|
||
|
|
||
Comment 17•24 years ago
|
||
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
|
||
Comment 18•24 years ago
|
||
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
|
||
Comment 19•24 years ago
|
||
according to the quantify data from 02/12/01 22:23 JavaScript takes arround 37%
of the new window (37.15, 1869789.41, 758, js_Interpret). Stupid question from a
non Mozilla hacker: why is JavaScript needed when opening a plain new window,
and why does it take soooo much time? How hard is it to reduce this time?
|
||
Comment 20•24 years ago
|
||
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.
|
||
Comment 21•23 years ago
|
||
*** Bug 100210 has been marked as a duplicate of this bug. ***
|
||
Comment 22•23 years ago
|
||
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.
Keywords: qawanted
|
||
Updated•23 years ago
|
Keywords: mozilla1.0
|
|
||
Updated•22 years ago
|
Target Milestone: mozilla1.0.1 → ---
|
||
Updated•15 years ago
|
Assignee: general → nobody
QA Contact: desale → general
|
||
Comment 25•7 years ago
|
||
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 ?
|
||
Updated•6 years ago
|
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•