Closed Bug 77051 Opened 23 years ago Closed 22 years ago

Linux popup menus painfully slow (too many calls to XGrabPointer and XGetGeometry)

Categories

(Core :: XUL, defect, P3)

Product:
Core
Component:
XUL
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
mozilla0.9.9

People

(Reporter: jg, Assigned: blizzard)

References

Details

(Keywords: helpwanted, perf)

Attachments

(4 files)

jprof output --enable-debug, -O2, JPROF_FLAGS="JP_DEFER JP_FIRST=3 JP_PERIOD=0.0015"
192.68 KB, text/html
Details
Output from xscope for context menu activation
18.71 KB, text/plain
Details
jprof: 10 right clicks JP_PERIOD=0.0020 stopped and started for each
567.84 KB, text/html
Details
jprof profile data; see comment #61
129.97 KB, application/x-gzip
Details 
This issue has been bugging me for months, it's time to file a bug so I can
blame other people when everyone on Linux calls mozilla1.0 "too slow for daily use".

Basically, right-clicking on a webpage to pull up the popup menu takes (on my
machine) around 0.5secs (very unscientific measuring). This should be
instantaneous, as every other app - be it TCL/TK, GKT, Qt, etc., pop up menus
instantly with no perceivable delay.

This is heavily affecting the main menubar too - the one containing File, Edit,
View, ..., Help, etc., and can be demonstrated by hovering over File (don't
click to bring up the menu, it'll only slow this demo down even more), then
moving across the other menus are a reasonable speed. _Very_ often one or more
menus are 'skipped' as the mouse travels over them faster than they can react.

This is bad. Many, many people I have talked to say that they are sticking to
Nav4.x because Mozilla is way too bloated. I believe this bloat is perceived
from the fact that our UI speed on Linux sucks.

This is hurting our Linux take-up hard. Reaction to User Events is perceived to
be poor. We need this taken seriously to get Nav4.x banished from Linux desktops
for good.

For reference, my machine:
K6-2 300Mhz
256Mb RAM, 128Mb swap, tons of hard drive space
XF4.0.2 (occurs with much older X servers/clients)
GNOME-1.4 (seen with 1.2 as well), GTK1.2.10 (tried with older 1.2 versions,
same effect)
Other apps are fine speed-wise.

CCing some Linux people, and hyatt.
Keywords. I consider this a high-profile perf bug, so topperf, and nominating
for 0.9.l and 0.9.2 radars.
Keywords: mozilla0.9.1, mozilla0.9.2, perf, topperf
This takes up to 5 seconds on some pages.

http://slashdot.org/article.pl?sid=01/04/21/0148202&mode=nested

took about 4.5 seconds (wristwatch timed), and hyatt said that it took < 50ms on
win32.
cc dbaron, who I *think* said he's profiled some of this stuff...

cc syd who apparently knows about such things...

This may seem nonsensical, but the context menu popup is noticably slower when
text is selected. That slashdot page is far from the worst example of this.
linux nightly build here (2001042106), Xfree 4, gnome 1.4, gtk 1.2, k6-2 350,
160 megs ram..

I have no problems whatsoever with context menu's/popups/tool bar menus/etc ...
infact i thought they were doing really well for the last few months,... grab a
build from about 8 months ago and the same thing couldn't be said (well at least
for me apparently)... 

i tried that slashdot link , menu's poped up very quickly (with or without text
selected... ) toolbar menus were quick to respond, looks good to me here...
Keywords: nsCatFood
Ok, I just tried two builds in addition to mine. Both were slower. 

I tried today's (4/21) gcc build and the normal build. Both were also slow on my
system, although my build with -O3 -march=i586 was faster. In light of this, I
doubt it has anything to do with compiler options.

If you look at the jprof output, the most time taken is in nsCRT::strncasecmp.
If you trace that back up, you end up in wallet.

This isn't because this is the first time to load wallet - I get almost
identical results if I open the context menu once before profiling (on exactly
the same page). No text is selected in the browser.

The call stack (involved in what appears to be about 138/222 of the times the
1ms timer went off - ie about 62%) appears to implicate
wallet_GetSchemeFromDisplayableText, with the following routines also involved:

TextToSchema(nsString &, nsString &)
wallet_GetSchemaFromDisplayableText(nsIDOMNode *, nsString &, int)
wallet_ResolveStateSchema(nsIDOMNode *, nsString &)

The root of this appears to be nsWalletlibService::WALLET_PrefillOneElement.

Can someone else confirm this?
Whether you see this may depend on your prefs or what you've used wallet for.

The two call sites where it could have entered WALLET_PrefillOneElement through
JS seem to be in walletOverlay.js (line 184) and contentAreaClick.js (line 38).
 I really don't see why either of them would have been called.
OK, please ignore my comments and profile data. It turns out that the wallet
overlay which enables/disables the various form/wallet stuff on the context menu
does what could be considered to be the wrong thing on forms containing lots of
select-one popups, like the /. patch I was testing. I'll file a separate bug,
attach a patch, and let the wallet owner work out if this is the right thing to do.

Even with this patch I still see the 0.5 second delay though.
Possibly related to CPU speed, too?  Even on Windows, I notice that scrolling in
Bookmarks Manager, and the speed of the menus (dropdown or popup) are very
noticeably slower on my 450MHz Celeron, compared to my 600MHz Athlon.  The
Celeron isn't *that* much slower, but it is an original Celeron, with no L2
cache.  Nevertheless, Mozilla seems to be the only app that has such an extreme
speed problem that I've seen.  (I'm guessing possible CPU speed since James
Green mentions his machine is 300MHz).
I did some testing last night on windows, and I think that I see the problem
there as well. Its just less noticable, because on windows the context menu
appears on mouseup, while on linux it appears on mousedown. (this behaviour is
as designed).

Am I seeing things? Can someone else verify that for me?
I've gone as low as 400 mhz on Win32, and the context menus remain native 
speed.  I even tried the slashdot page with text selected as you suggested.  
Still fast.

I believe there are Linux-specific issues with the widget code that handles 
popups.... not with the XP menu implementation.

i'm sorry but i've been using quite a few builds on Linux x86, Linux PPC and
MacOS and i did notice those slow popups you're talking about !?! the only slow
popup i've noticed is the bookmarks menu when you have lots of bookmarks in it.

(my 2 eurocents...)
The wallet spinoff bug is bug 77073.
over to unix weenie...not that i really think this is a problem. i'll let dr sort 
it out.
Assignee: pinkerton → dr
Ok, ok. This isn't a catfood issue, and just because you consider it important
doesn't make it topperf (a very high-profile performance issue, on par with
issues like the xul tree widget being inappropriate in mailnews). Let's chill
with the keywords.

I'll target this at 0.9.1, at P4 until somebody starts making sense. No offense,
but there's a *lot* of noise in this bug.
Status: NEW → ASSIGNED
Keywords: nsCatFood, topperf
Priority: -- → P4
Target Milestone: --- → mozilla0.9.1
> but there's a *lot* of noise in this bug.

Yeah, sorry about that. When this was mentioned on IRC, I was testing on the /.
page which took 7 seconds. (see the spinoff bug)

I'm not sure whether this is slower on normal pages - there is a small delay,
but I don't know if its really more than on windows.
based on conflicting comments (as to whether this is a linux bug, whether this
is a bug at all, etc.) and piles of noise, i'm going to resolve this bug as
invalid. don't let this hurt your feelings, though :) -- if you're still seeing
a problem with this which you can quantitatively analyse, file a new bug on me.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
This is the reason, the ONLY reason, why I don't use mozilla. I thought someone
in #mozilla had told me the issue was being worked on, but after recently trying
0.9 and seeing no improvement, this is the only bug I could find on it.
Everything else on Linux seems fine, but XPFE is unusable. 2+ seconds for the
prefs dialog. 0.5-1.0 seconds for the right-click menu, which I make heavy use
of. 5+ seconds for new windows, which is how I open 75% of links. All these
operations are instantaneous with Netscape 4.7x. Mozilla is a big improvement
over Netscape 4.7, but unless XPFE perf is fixed, I will absolutely never be
using it. As I haven't had a MS Machine in months, I haven't even been able to
do QA because of this severe performance issue under Linux.
I agree. Opening new window is far too slow (should be <<<< 0.5s for an empty
window).

Popup menus:
- right clicking on various parts of this page show the context menu in about
one second (manually timed). Celeron 466/128MB.

Target:
- should be as fast as menu bar submenus (they are acceptably close to speed of
native menus).
i agree. now, where the renderer got pretty fast, the GUI still is/feels pretty
slow under Linux. The contrast between the fast and the slow parts makes the GUI
feel even slower...

Is this worked on? is there a tracking bug? 

There are lots of bugs about new windows performance (eg bug 49141). But I don't
know, if there are bugs about extremly slow appearing of the "save as", "open
web location", "open file", "preferences", "file bookmarks", "manage bookmarks"
dialogs. Also opening Mail and Composer from the browser takes several seconds.
These performance problems should be handled to make Mozilla a real pleasure to
work with. 
I am using a P3-550. While it is not a state of the art machine anymore, it
should be overkill handling a GUI. So for me it is a bug, if relativly simple
things as showing a dialog take over a second to display on such a machine!

Dan: I am not sure, if these problems are the same as this bug or if new bugs
should be filed.
just found http://mozilla.org/quality/perf/browser-archive/preferences.html for
performance measurings for the preference dialog. seems like this dialog got
slower over the time :-/
This is a difficult bug. When I filed it I was seeing popup menus in around 2
seconds, which is unacceptable. Since my last comments I have examined the
situation and found bug 53486. I have since been building with -O2 compiler
optimisation.

The build was clobbered and then built with the new compiler flag. My first
impressions is that with -O2 the UI has cut it's response time in half. Whilst
this is very good news I perceive that we are still twice as slow as other GTK
apps in pull-down menus and popup menus.

In fact, moving the mouse between File, Edit, View, etc., back and forth over
them, there is considerable delay. In many occassions the menus appear to 'skip'
a middle menu and instead catch up to the pointer on the next menu.

So we are faced with fairly daunting task. There are a number of bugs filed
which could easily affect UI responsiveness, many of which were filed for
Windows but which are actually XP. Others are big performance bugs being worked
upon that may or may not have a bearing on Linux UI performance; I have no way
of telling and in many cases the engineers know little about it either.

I do however make the assumption that we are aiming to have menus as fast as
native ones. I say that because I know there is an awful lot of code in the
product which gets used perhaps as a middle-man (XPConnect etc??) of which I
know little. Could this be the reason menus are slow? If that is the case,
wouldn't all platforms be in the same boat?

It seems not. From the figures I have seen, we are fastest on Windows (pretty
much native speed) which is where the marketing department has the most clout,
then Linux (in some cases 30% down on Win32, in some cases much slower), then
Macintosh (quite slow apparently).

The trouble is - how do we tell if what we are seeing is general performance
problems in the product or Linux-specific issues?

I am able to run VMWare here, and have installed Win2KPro (SP2). I installed a
recent nightly and tried the menus out. Bear in mind that any OS running in
VMware will be slower than native for obvious reasons. My findings are that we
are slower, but most noticably in pull-down menus such as File, Edit, View, etc.
Pop-up menus are somewhat slower, but much less profound than pull-downs.

I know this because in Win2K within VMware, File, Edit, etc., responded much
quicker than the same menus in a Linux build. This is the opposite of what we
should be seeing.

I'm going to reopen this bug. If someone can get some performance data on
linux-specific UI problems and give it here, I'd be grateful. I have a debug
build, but no idea how to measure such issues. Also, I think we should wait
before pouncing on this bug until the main other app-wide issues are sorted out;
such as DHTML and style slowdowns. Hyatt, waterson, attinassi, jst and brendan
are amongst those working on these issues, and once they have been cleared up to
the extent that the Win32 builds are nice and speedy, then we can justifiably
moan about Linux builds if we need to.

I note that dbaron says the gcc compiler may also have weaknesses that are being
exposed here. With gcc-3 still in it's infancy, there might not be much we can
do on that matter.

I'm marking this bug as Future on dr's behalf, until we can be sure that other
app-wide issues aren't causing the poor performance, or until someone identifies
Linux-specific issues that can be improved.

By the way, it would be most helpful if the testers here could comment on
experiences with machines slower than P400s. I have a P300 and see plenty of
performance bugs than P400 users say is perfectly acceptable.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Target Milestone: mozilla0.9.1 → Future
Re: request for testing under 400mhz.

My main workstation is a P2 266 with 256M of RAM, and I have NO plans to
upgrade/replace it in the next 3-4 years. It's more then fast enough for every
app I run, and I do quite a bit of compiling. Netscape 4.7x has instantaneous
respose, other GTK apps have instantaneous respose, but Mozilla 0.9 is a joke.
Any benefits from it's superiour rendering engine are negated twenty times over
by the abysimal speed of XPFE.
A profile I just took of opening and closing popup menus shows a lot of time
being spent in the style system -- much of which could go away with hyatt's
rewrite.  How is the performance here on hyatt's branch?  (I should re-profile
with a branch build, except I don't have one right now.)
David: could you profile the following:

- Opening the File menu
- Moving from the File menu to the Edit menu

The opening, and moving between menus operations are very slow on Linux indeed
compared to X-Chat.

david:
I just tried a build with hyatts Style changes. while it got faster here and
there, it is still too slow. Opening the preference window still takes over a
second to open on a P3-550, so it is probably annoying slow on a 300Mhz machine.
I would be pleased if you could do a new profile, once Hyatts changes entered
the tree :-)
I profiled switching between File, Edit, View, and Search.  Here's a summary of
a few things that stand out (I may add more later):

9.6% of the time in XGrabPointer, called from:
  gdk_pointer_grab
  nsWindow::NativeGrab
  nsWindow::CaptureRollupEvents
  nsMenuDismissalListener::SetCurrentMenuParent
  nsMenuFrame::UpdateDismissalListener
  nsMenuFrame::OpenMenuInternal
9.4% of the time in StyleSetImpl::WalkRuleProcessors (mostly selector matching)
8.7% of the time in XGetGeometry, called from:
  gdk_window_get_geometry
  nsDeviceContextGTK::GetRect       [ could this cache the value? ]
  ScreenImpl::GetLeft               [ and a few from GetTop ]
  nsMenuPopupFrame::SyncViewWithFrame
  nsMenuFrame::OpenMenuInternal
8.3% of the time in nsBoxFrame::GetPrefSize
6.2% of the time in NS_NewStyleContext (mostly selector matching but also some
          style data copying and comparing that should be fixed with hyatt's
          branch)
4.6% of the time in JS and XPConnect code excluding the time calling back
     into C++ code through XPConnect
4.4% of the time in nsXULElement::GetAttribute [ most of this is a subcategory
                                                 of the other things above and
                                                 below ]
2.6% of the time in nsCSSRendering::PaintBorder (mostly X-server communication)
2.4% of the time in nsRegionGTK::Union, mostly called from:
  nsWindow::Invalidate
  nsViewManager::UpdateAllCoveringWidgets
  nsViewManager::UpdateView
  nsBox::Redraw
  nsBox::SyncLayout

re: the above profile

XGrab looks to be the killer. If you didn't release the mouse while moving from
File to Search menu item there should be at most 1 XGrabPointer call during this
time (it should happen when the mouse is pressed and last until the last
pulldown is dismissed)...

XGrabPointer forces a server roundtrip and is a "slow" call... 

Something is broken as designed here...

Also it seems to me that:
  - gdk_get_geometry is called lots of times to get the screen geometry...
    it should only be done once since the screen geometry is unlikely to
change... (X doesn't support this unfortunately and even if it did it should
send an event when this happens).

Can you set a breakpoint somewhere to verify that it is indeed querying the
screen geometry.

Even if it is querying the window frame geometry, it can most likely be cached
for the duration of the grab (at least).
Blocks: 49141
Hm, this is interesting profile data. I'll try to find out if I can take this on
for 0.9.2. If not, then helpwanted :)
Status: REOPENED → ASSIGNED
Keywords: helpwanted
bugs we know can help speed up window open performance:

bug 70647 implement brutal sharing for XBL methods and properties
bug 75672 optimize command updating when command has no visible UI element
bug 77999 cache rule processors for XUL scoped and UA stylesheets

and also hyatt's CSS improvement branch
bug 78695 [CSS] Rule matching performance improvements

dr, can you help identify any issues that will help speed up popup menu?
especially if those known bugs, so we can put a spot light on them, and if any
other new issues that we need to know about?

lets figure this out and see what we can do for 0.9.2.

Jeremy: I don't want to pull you into a flamewar in my bug here, but you should
do a little research before you make certain incendiary statements:

> Any benefits from it's superiour rendering engine are negated twenty times
> over by the abysimal speed of XPFE.

The XP front end is driven entirely by the rendering engine. There isn't a
tremendous amount of difference between the codepaths taken to render a webpage
and those taken to render our UI. I should also mention, we're not talking about
dialog boxes here in this bug (Jens-Uwe, hören Sie gut zu?), we're talking about
popup menu performance. There are bugs filed on window-opening performance and
always n.p.m.xpfe to discuss this. No need to confuse Cathleen, nor to spam a
perfectly good bug.

Point being, Marko's summarization of David's profiling data here is astute.
Pavlov is said to have made the claim that we have to call XGrabPointer as much
as we do (which would imply that X is as horrible as all its naysayers make it
out to be), but if that were the case then all X apps would be as slow as we
are. It's also entirely possible Pavlov never said that at all :) Either way, I
think there's a better way our unix menu code could be written. We at least
shouldn't be querying the screen geometry for each call to open a menu...

I'm going to take this into 0.9.3, on trudelle's advice to keep it "close to the
radar" and maybe see if I can get it into 0.9.2 in a few weeks.
Priority: P4 → P3
Summary: Popup menus are too slow → Linux popup menus painfully slow (too many calls to XGrabPointer and XGetGeometry)
Target Milestone: Future → mozilla0.9.3
For a good time, see bug 19199...
Blocks: 83395
I'd also vote for this bug. Even sice the menu speed is acceptable to me.
Here it what I think should be improved:

~2s to open a new empty window
~1+s to open the preference dialog

My box is 850MHz Atlon/256MB (Debian Woody/Gnome 1.4). 

And just a notice (so do not flame me ;): Look at opera - it's not _that_ fast
as it seems to be when you look at it but it takes a quick response for typical
actions like new-window, back (they're probably somehow cheating). Even some
visible animations make it "more responsive". Users tend to say "network is slow
I can wait a second" but they are very intolerant to any GUI slowness. (Remember
the cursor in XFree 3.3.x).
To repeat: we are _not_ covering new window speed, or Preferences speed or any
other window opening speed here - that's covered by many other bugs which in
turn are handled by bug 49141. This bug is solely covering popup menus and
drop-down menu performance, the latter is the worse of the two.

If anyone out there can identify other [potential?] causes of performance
problems in our Unix/Linux/GTK port, then new bugs should be filed; if there
enough of them, we'll file a tracking bug to cover them all. But let's not cover
more than one issue in this bug.

Too much noise. Removing noisy CC's. Go to the newsgroups to chatter. Come here
to help with *this bug*.
Another issue makes the percieved speed of the menus even lower:

the problem is when you move the mouse to the desired target item immediatelly
after clicking and before menu appears at all. The result: the item is not
selected even though the mouse is positioned on top of it. It's easy to
reproduce when the menus take 1 second or more to pop up.

This impairs muscle memory and makes the popup menus generally suck.
I can't reproduce the problem you mentioned in my month old build because the
menu comes up too quickly.

Does moving the mouse a pixel select it?  Or do you need to select another menu
item and then go back?  If the former, it's related to bug #20022.
Yes, if I move the mouse one pixel, the item is selected.

It looks similiar to bug #20022, but I am not sure if the underlying problem is
the same.
Marko: Hmm, interesting that you mention this -- I had a bug on exactly that
problem a couple months ago, but I couldn't reproduce it. I'll see if I can dig
it up again.
Well, whatever patch got in to 0.9.1 for the pulldowns, hopefully also can be
applied to popups. Pulldowns are now instantanious speed on my P2/266 (thanks,
whoever), unfortunatly popups seem to have gotten worse, up to about 0.8
seconds, from 0.5. And I'm seeing 100% CPU during that second, if that's any help.
I would confirm that drop-down menus have gotten faster recently, but that the
pop-ups haven't. I'm running the 2001060622 build on a 180MHz/128Mb SGI O2 under
IRIX. Drop-downs take about 1s to show initially, but become a lot faster after
that. Pop-ups take about 2s, each and every time, regardless of context.

I'd note that (1) this is a cross-platform bug, as far X/GTK-based
implementations are concerned and that (2) David's profiling may be misleading
for *this* bug as it was done against drop-down menus, rather than pop-ups.
IMO, the goal for responsiveness here should be that popups and drop-downs
appear within about 0.1 seconds; anything longer than that is perceived by most
people as being sluggish, anything shorter than that is imperceptible to most
people, and therefore could be a waste of effort and possibly even runtime.
Peter: agreed. Right now, in my tip build from this morning, popups (right-click
on a page) take just under one second (optimised build using gcc-2.95.4 and
-O2). I notice that it takes a tiny bit longer when right-clicking on this bug
report that on the much smaller page that is "Bug Posted". It's small, but
noticable.

Drop-downs are worse. In fact, I'm noticing very interesting behaviour there. If
I continually click on each drop-down's header item ("File", "Edit", etc.) I can
eventually get the drop-down to appear almost instantly. However, if I keep the
drop-down open, and move the mouse across the menus, there is a very noticable
lag which causes some menus to be skipped entirely. This could be some sort of
memory caching issue, I simply don't know the technologies involved.

For example, opening Bookmarks by clicking "Bookmarks" is almost instataneous,
yet moving between "View" and "Edit" (moving leftwards) it takes one second or
so to give me the Edit menu. The same can be said about moving from Bookmarks to
Go (with four Bookmarks folders in the menu, and eight non-folder bookmarks
shown, and ten items shown in the Go's history list).

If it wasn't for the fact that Bookmarks menu is so fast to open, I could be
conviced that building the Go and Edit menus were significantly slower than the
menus that didn't involve dynamic creation.

I also note that on moving between drop-down, at the exact point where one menu
disappears and the next appears, the mouse pointer flashes. Quite whether that
could be causing a slow down I don't know.

I am fairly sure that the mouse grabbing Linux code is to blame for the
slowdowns here.  On Win32, we don't have to do anything like that, and the menus
are plenty fast.  The problem is that when you move into a different popup
(i.e., a rectangle containing menu items), on Linux we then do a grab for the
widget corresponding to that popup.  My understanding is that this is a very
slow operation, and I asked pav if there was a way to implement the popup widget
code on Linux so that this didn't have to be done.  At the time, pav said it was
not possible to do it any other way.

The grab needs to happen for context menus and menu popups.  That's the way that
it has to be.

However, there are probably some operations that can be made faster.  For
example, I suspect that when switching between menus that are doing more grabs
than we need to.  We could grab on the parent instead of the child and just
redirect events to the child when it's open and avoid the ungrab/grab.

That won't work for context menus, though.  I need to know what the really
expensive operation is for context menus in order to fix them.  I suspect we can
make them much faster since they are faster with grabs on native toolkits.

I need numbers, not whining! :)
->blizzard
Assignee: dr → blizzard
Status: ASSIGNED → NEW
I've created an attachement with the output of "xscope -q" on my trusty SGI
(spec'ed above) that shows all the X calls to and from Mozilla during a context
menu event. I just loaded mozilla (build 2001063021), went to the m.o homepage,
waited a while, and then hit the right mouse button.

I've edited it down to only show the period between the mouse click and the menu
being shown. I'm not an X programmer, but I hope this helps. I can produce a
hideously more verbose version if that would help.

The context menus now appear in about a second, which is 50% faster than the
build I was using when I posted 3 weeks ago. Looking at the xscope figures, the
whole operation took 1.36sec. I don't know what work has been done to improve
this, but there are only 2 XGrabPointer and 4 XGetGeometry calls calls made, so
maybe that was a red herring.

Notice that there is 0.57sec (42% of total) between the mouse-up and the first X
call from Mozilla, so maybe there are gains to be made elsewhere. Also, there
are 16 XCreateGC calls made at the 56.26sec mark, but this is very close to the
number of menue items (14) so I'll shut up now and stop adding to the noise.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Sorry to add to the noise. Here's my experience on my 450 PIII RH7.1:
menu bar menus pop up quit quickly except for the edit menu.  Various nightly 
builds are faster than others but the Edit menu seems to be a problem.  This 
was verified on a gtk build as well as an xlib build.  This slowness is not 
nearly apparent on an identical machine running Win2k with the same build date.
Additionally I'm seeing slowness in the right-click-on-a-page menu as well as 
the completions menu that comes up when typing in the url bar.  Hopefully I'll 
have some jprof output to back this up if I can figure it out.
I added a jprof of the right-click-menu.
This is 9/6/2001 source built with xlib on linux.
Because of the stochastic nature of jprof, I decided to do 10 right clicks by 
running the following:
sleep 10; ./jprofsig start; sleep 4; ./jprofsig stop
During the 4 second profiling period I would right click once on a web page but 
not move the mouse.  Hope this helps.
Next up comes a profile on the same machine but with gtk instead of xlib.

Was this profile done with JP_REALTIME?  You need that to show time spent
waiting for the X server.
I just did a JP_REALTIME profile of repeated right-click, then left-click on an
HTML page for 60 seconds, and it only showed gdk_pointer_grab taking 14% of the
non-|poll| time.  I think there were some times my clicks didn't actually bring
up a context menu, though, so it's probably a bit higher.
Blocks: 99053
*** Bug 99875 has been marked as a duplicate of this bug. ***
Moving out.
Keywords: mozilla0.9.2
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Target Milestone: mozilla0.9.6 → mozilla0.9.7
I have a pentium II 233MHz running redhat 7.0 and am using mozilla 0.9.6. I have
been trying to profile this, this what I have done so far.

I have been taking measurements of how much cpu time mozilla uses after a right
click event by reading the UTIME and STIME fields of /proc/#/stat before and
after opening the context menu. On http://www.mozilla.org this is ~310
milliseconds. Timing opening a context menu with my alarm clock gives about the
same figure. It seems like there is NO significant time waiting for events and
people will have to find some other reason to whine about X, this preformance
problem is purely in mozilla's process.

I can only get ordinary jprof profiling to go down to 20 ms samples, and
JP_REALTIME profiling to 10 ms. This gives only about 16 and 32 samples
respectively, and each in a different function. It doesn't seem very useful to
me. I have html outputs and raw sample stack dumps of both JP_REALTIME and
otherwise profiles if anyone's interested.

Can the linux kernel be tweaked to have a higher internal clock rate, to useful
effect? Is there any way to usefully use eazel's instrumenting profiler (or some
other one) with this?
Try looking in the kernel source. I think there is a setting like: 'herz=', I 
forget the precise file, but changing that to a higher value may help.

I have indeed managed that, for reference you up the #define HZ in
include/asm/param.h to do it, nothing else seems to be necessary everything
already supports wacky HZ values. I compiled a kernel with 1000 hz clock for my
 profiling, where the default is 100. I profiled with JP_PERIOD=0.002, which
gave me 2ms per sample JP_REALTIME and 3ms otherwise.

I don't consider them very exciting but I'll upload a .tar.gz with 6 files of
data from 3 profiles. each profile has the ordinary jprof html file
(profile*.html) and a raw data file which is basically jprof-log with symbols
resolved and human readable (stack*.txt). The stack dump files are a list of
sample stack traces each in the format
<num> -->
<stack dump>

I'm sure you can figure out what the stack dump is, the number is the
milliseconds passed (in real time) since the profiling was started.

The three profiles I did are named "", "-realtime" and "-slashdot". The first
two are done with http://www.mozilla.org open, -realtime with JP_REALTIME set.
-slashdot was done without JP_REALTIME on www.slashdot.org.

profiling was done like this:

1. Load mozilla, go to the appropriate web site, right click once or twice to
get everything loaded. I also had the sidebar open for these tests.
2. open a terminal window and "sleep 5;./jprofsig start;sleep 1;./jprofsig
stop". I think I slept 2 seconds during the profile for slashdot though.
3. Move the mouse back to the mozilla window, raise it, focus it, prepare to
open the context menu.
4. When profiling starts, right click. I didn't close the context menu or
otherwise move the mouse (I hope) until the profiling stopped though.
5. When it stops, close mozilla.
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Approximate timings for menus, Linux 2001122708. P2 266.

Context menu on this page, first click: 0.6s
Context menu on this page, subsequent clicks: 0.3s

Context menu on bugzilla banner on this page, first or subsequent clicks: 1.2s

0.3s for the subsequent body clicks is a slight improvement, but many places,
for example, the bugzilla banner, which is just an <a href><img>, are still
incredibly slow.

In comment 27, dbaron said hyatt's rewrite of the style system would help... is
that comment still relevant, and was it done? The new context menus should help
somewhat, but they're caught up in nasty NSCP politics.
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Now looks like normal popup menus are quite fast, but context menu in bugzilla
banner is still very slow. It eems to be same with all images, context menu is
slow, but all other context menus are fast (over link or in form).

I looked with xmon what difference there is xrequests when right clicking
on page and clicking on image. Most of call counts stayed same, just
some are different:

Image  Plain   Function
------+-------+-------------
 17      7     CreatePixmap
 17      7     FreePixmap
 85     30     ChangeGC
 85     32     SetClipRectangles
 17      6     CopyArea
121     33     PolySegment
 54     31     PolyFillRectangle
 44     26     PolyText8

I only see 2 XGrapPointer and 4 XGetGeometry calls in both cases.

I Run eazel profiler and when clicking on bugzilla banner, most of time
seems to go to nsPopupSetFrame::OnCreate() (calld 1 time and takes 1500ms)
There is suspicious HandleDOMEventWithTarget() in OnCreate()
wich also seem take long time. (called 4 times and takes 1504ms)

I also compared clicking on elsewhere on page to clicking on image.
When clicking on image nsGlobalChromeWindow::AddRef() and ::Release()
are called 27124 times, elsewhere on page just 1988 times.
nsPopupSetFrame::OnCreate elsewhere on page takes just 300ms

I think i find out why clicking on image is slower. I commented out image 
blocking code in extensions/cookie/resources/content/cookieContextOverlay.xul
and everything runs fast.

Commented out code:

      initImageBlocking : function () {
        try {
        // Block image depends on whether an image was clicked on, and,
        // whether the user pref is enabled.

/***********************************************************************
        gContextMenu.showItem
          ("context-blockimage",
           gContextMenu.onImage && cookieContextMenu.isPrefSet() &&
           cookieContextMenu.isBlockingImages());

        gContextMenu.showItem
          ("context-unblockimage",
           gContextMenu.onImage && cookieContextMenu.isPrefSet() &&
           !cookieContextMenu.isBlockingImages());
********************************************************************/
        } catch (e) {}
      },

I have only 8 image blocking sites but about 500 cookie sites, are they saved
in same place? Should that slow down?
I opened bug #146048 for my last comment.
Popupmenus seems quite fast now, i mark this as WFM.

Blizzard has bug #141198 about general linux menu speedup.
Status: NEW → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → WORKSFORME
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
No longer blocks: 99053
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: