Open Bug 1377768 Opened 2 years ago Updated 6 months ago
high cpu load due to gdk
_x11 _drag _context _get _type when moving the mouse
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0 Build ID: 20170616092053 Steps to reproduce: 1. open a fresh install of firefox (tested ff49, 54 and 56 nightly) 2. disable all plugins 3. open bugzilla page 4. start making circles with the mouse in an empty area. Actual results: My laptop CPU is very slow in battery mode and the usage of it went up to 60-80%. Chrome stays at about 10%. I ran a profiling session: https://perfht.ml/2tyNrT9 After start I wait about 5 secs -> low usage Then i move the mouse in circles for 20 secs -> 60-100% cpu load At the end i stop the mouse again for about 5 secs. The profile shows > 90% of time spent in poll (libc) called from PollWrapper (libxul). Expected results: A similar CPU usage as chrome. This is not so much a performance problem, but a battery saving problem, as the cpu has to wake up very often. Firefox should be more intelligent about when and how often to poll for the mouse position. I'd say that not every position update is important. I don't know whether there is a frequency limit (don't poll more than, say, 30 times a second), but there should be. and probably it's possible to do even more with heuristics (is js tracking the mouse position, are there elements near the cursor, which need an update, how fast is the mouse going).
I think the changes from bug 963158 and/or bug 429592 make it difficult to see what's going on in this profile.
Component: Untriaged → Widget: Gtk
Product: Firefox → Core
Hey Adam, Were you click-dragging when you gathered this profile? gdk_x11_drag_context_get_type seems to dominate it: https://perfht.ml/2tQ0hKz
I also see us inside nsBaseWidget::ProcessUntransformedAPZEvent a whole lot: https://perfht.ml/2tPVgkV Hey botond, is this expected?
Hi Mike, right. i completely misread the profile. Obviously it spends most of the time polling, but it's not busy waiting.. I'm updating the title accordingly. No, I was not click-dragging. I might have used the touchpad, accidentally click-dragging, but I verified it now in another profile using the mouse: https://perfht.ml/2ui24uA Again, a lot of time is spent in gdk_x11_drag_context_get_type
Summary: high cpu load due to libc polling for mouse position → high cpu load due to gdk_x11_drag_context_get_type when moving the mouse
(In reply to Mike Conley (:mconley) - Digging out of needinfo / review backlog. from comment #4) > I also see us inside nsBaseWidget::ProcessUntransformedAPZEvent a whole lot: > https://perfht.ml/2tPVgkV > > Hey botond, is this expected? It is expected that ProcessUntransformedAPZEvent is called for every mouse event. It's not expected that we spend so much time inside that function. Looking at the profile, it looks like we're spending an inordinate amount of time - about 68% of all time - in gdk_window_get_origin (and more specifically, polling inside xcb_wait_for_reply inside of that, so I'm guessing waiting for a response from the X server). So, perhaps the X server on the affected system is very busy doing other things, and Firefox spends a lot of time waiting for responses from it?
no, the x server was not busy. without mouse movement, the cpu was idle. besides, why would the cpu usage go up during waiting (i suppose it isn't a busy wait)? but at least that would explain, why the x-server also becomes busy (see also https://bugzilla.mozilla.org/show_bug.cgi?id=1307134). isn't it possible to cache the window coordinates? or use a callback or something.. anyhow, the problem is smaller in thunderbird for instance. what's the difference there?
(In reply to Adam from comment #7) > no, the x server was not busy. without mouse movement, the cpu was idle. > besides, why would the cpu usage go up during waiting (i suppose it isn't a > busy wait)? Perhaps the CPU was being utilized by the X server, not Firefox? > isn't it possible to cache the window coordinates? or use a callback or > something.. We could employ mitigations like that on the Firefox side, yes. However, querying window coordinates is just one of the things we ask the X server to do, and Firefox is just one of several applications asking the X server to do things. So, if there is an underlying systemic issue that's causing the X server to be slow to respond, then investigating and fixing that is likely to be more useful. > anyhow, the problem is smaller in thunderbird for instance. what's the > difference there? Thunderbird might make fewer queries from the X server per mouse-move event. We could investigate why if we had a Thunderbird profile to compare, though some of it is likely to be unavoidable (due to Firefox needing to do more complicated things than Thunderbird, and having features like APZ that Thunderbird doesn't).
(In reply to Botond Ballo [:botond] from comment #8) > Perhaps the CPU was being utilized by the X server, not Firefox? firefox: 60 - 70% load x server: 10% kwin, or other stuff 3%, and the apps are changing in comparison: chrome (2 processes combined): 15% x server: 6-7% > (due to Firefox needing to do more complicated things than Thunderbird, and having features like APZ that Thunderbird doesn't) well, i guess chrome is doing those things more efficiently. i'd like to see ff also get there :)
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.