Closed Bug 68002 Opened 24 years ago Closed 6 years ago

Window.open() in javascript should be faster

Categories

(Core :: DOM: Core & HTML, enhancement)

Product:
Core
Component:
DOM: Core & HTML
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: colinp, Unassigned)

References

Details

(Keywords: dom0, perf)

Attachments

(4 files)

jprof report on that open-and-quit test
861.18 KB, text/html
Details
Quantify data of opening 4 windows using Ctrl+n
104.52 KB, text/plain
Details
Same quantify data that includes a F time column
118.71 KB, text/plain
Details
Top F times from the quantify data
1.62 KB, text/plain
Details 
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
easier said than done really...this bug is useless without a reason as to why it
takes so long.
can someone run quantify?
Assignee: asa → jst
Component: Browser-General → DOM Level 0
Keywords: perf, qawanted
QA Contact: doronr → desale
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
Keywords: dom0
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?

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.
Keywords: oeone
*** 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.
Keywords: qawanted
Keywords: mozilla1.0
Target Milestone: mozilla1.0.1 → ---
Mass-reassigning bugs to dom_bugs@netscape.com
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
Closed: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: