User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 Build ID: 20180516032328 Steps to reproduce: When opening a new tab, Firefox will occasionally freeze and stop working for roughly 0.5 to 2 seconds. While those hiccups aren't a major problem, they are a constant annoyance. From my observations, this is most likely caused by multiprocess support: When opening a new tab Firefox also starts a new Web process if it's below its limit of processes. Opening this new process seems to be what's causing the browser to temporarily stop working. Ideally Firefox can solve what's causing the hiccup internally. If this is a system issue, a workaround would be to open the maximum number of Web processes when Firefox starts, rather than opening and closing them dynamically based on tab count: While this might cause a bit of extra memory to be used, it might be better than FF hiccuping as you open new tabs. It should be noted that I'm noticing this issue on Linux (openSUSE Tumbleweed x64). I'm not aware whether it's also the case on Windows.
Hi, I tested this on Ubuntu 16.04 with Firefox 60.0.2, but could not manage to reproduce it. It does not take more than a half second to open a new tab. However, I am not on OpenSUSE, so that could be one reason. Could you please provide a profile using the gecko profiler addon? Steps are here- https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem Thanks test env't: ---------- Version 60.0.2 Build ID 20180605171542 Update Channel release User Agent Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
(In reply to Abe - QA (:Abe_LV) from comment #1) https://perfht.ml/2yrwFsN I started a new instance of Firefox, opened random sites from my history, and should have captured at least one if not two of the freezes. Indeed they only last for roughly 0.75 seconds, but that's still a noticeable time. Is there an option to preemptively start every Web.exe process with Firefox and disable the dynamic starting / closing of those processes? I'm curious if that will fix the problem, which I suspect that it would.
@mconley, what is your suggestion on this profile, comment 2? Thanks
Hm. Some pretty funky behaviour going on here when launching the content process. There's a significant chunk of time missing in the main thread of the new content process when the parent process is being blocked in LaunchSubprocess. Presumably, this is before the profiler has actually started sampling in the process, so it's pretty early on. So the profile doesn't tell us much, except that there's a block box before sampling that we need better visibility into. The perf profiler on Linux might be a better choice here. Hey rjesup, do we have the capability of loading perf profiles in perf.html yet? And if so, is there a guide on how the reporter here could gather a profile for us to look at with it for his content process start-up?
Component: Untriaged → DOM: Content Processes
Flags: needinfo?(mconley) → needinfo?(rjesup)
Product: Firefox → Core
The symbols in the profile in comment #2 seem very wrong. Maybe this would work better with one of Mozilla's official builds? Even so, if I right-click the ContentParent::LaunchSubprocess frame and choose “Focus on subtree”, it definitely seems to be doing *something*, calling and returning from various functions, and not just blocking; if it were blocked I'd expect to see the same stack for many consecutive samples. I also notice that the first 100-150ms of the mystery time are spent in libfontconfig, which is worrying, and might have something to do with the larger 1-2s mystery time after that. (The library name should be reliable, even if the symbol names aren't.) Maybe this is related to bug 1412090?
This is interesting. I was sure what I'm seeing was a common issue (at least on Linux). I would be happy if someone could better explain what's causing the slowdowns so we know: If it's a bug in Firefox this hopefully helps find it... if it's a compilation issue, perhaps we can let the openSUSE team know about it.
(In reply to Jed Davis [:jld] (⏰UTC-6) from comment #5) > I also notice that the first 100-150ms of the mystery time are spent in > libfontconfig, which is worrying, and might have something to do with the > larger 1-2s mystery time after that. (The library name should be reliable, > even if the symbol names aren't.) Maybe this is related to bug 1412090? (and maybe bug 1439412 would help? In any case, probably qf- since this is Linux-only which puts it out of scope for qf)
Depends on: 1439412
Whiteboard: [qf] → [qf-]
You need to log in before you can comment on or make changes to this bug.