Closed
Bug 710068
Opened 13 years ago
Closed 7 years ago
3-4 seconds delay loading page with many (30+) Flash plugins
Categories
(Core Graveyard :: Plug-ins, defect)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: jrmuizel, Unassigned)
References
()
Details
(Whiteboard: [SPS][Snappy:P1][telemetry-needed])
Attachments
(3 files)
8.00 KB,
text/plain
|
Details | |
5.61 KB,
text/plain
|
Details | |
3.78 KB,
patch
|
Details | Diff | Splinter Review |
This looks like it's being caused by plugin stuff: For example we spend a lot of time in nsNPAPIPluginInstance::InitializedPlugin() waiting for the plugin. I'll try to get more information as it becomes available.
Comment 1•13 years ago
|
||
> This looks like it's being caused by plugin stuff
Odd. I can load that page with all my plugins disabled, and don't see any errors or missing plugin icons.
Comment 2•13 years ago
|
||
(Following up comment #1) I also don't experience any delays.
Reporter | ||
Comment 3•13 years ago
|
||
For what it's worth, I'm using flash 11.1.102.55 on OS X 10.6
Reporter | ||
Comment 4•13 years ago
|
||
Here's a log of the functions times. Some of them are above 300ms and I expect that we schedule all of these function calls in one bunch, which means we're away from the main loop for the sum of all the times.
Reporter | ||
Updated•13 years ago
|
Whiteboard: [SPS] → [SPS][Snappy]
Comment 5•13 years ago
|
||
(In reply to comment #4) These are all from loading this bug's URL? Even though I was able to load that page with all plugins disabled? I guess I'll have to write a logging patch, and see what it turns up. Also, how did you measure the times? I suspect the times for nsObjectFrame::InstantiatePlugin() are normal, and we may not be able to do anything about them. What's puzzling, though, is the large number of calls.
Comment 6•13 years ago
|
||
OK, visiting this bug's URL *does* load a plugin -- the Flash plugin. In fact it loads the same Flash file 35 times (in my tests)! I don't know whether this is our bug, or simply unfriendly behavior by the github site. I aim to find out. I've also now noticed the delay. It's only 2-3 seconds, but that's enough to make it easily visible if you're looking for it. I'm going to check the behavior of older FF versions, and of other browsers. The delay doesn't happen if you've disabled the Flash plugin, but there are otherwise no visible differences. I'm also using Flash 11.1.102.55, on OS X 10.6.8.
Comment 7•13 years ago
|
||
That this bug's page loads the same swf file 30-40 times isn't a Firefox bug -- it also happens in Safari. So the question becomes: How do we compare performance on this (very unfriendly) page with other browsers (like Safari and Chrome), and how might we improve it? I don't know the answer to either. But subjectively, Safari's performance on this page seems *much* worse that Firefox's (FF 8.0.1 or today's mozilla-central nightly). And Chrome's performance seems about the same.
Comment 8•13 years ago
|
||
By the way, here's how to use gdb to detect calls in Safari to any plugin's NPP_New() method: Run Safari and load an example of the plugin you wish to test. Then do 'ps ax' from a Terminal prompt and look for an instance of /System/Library/PrivateFrameworks/WebKit2.framework/PluginProcess.app/Contents/MacOS/PluginProcess corresponding to this plugin. Attach to this process using something like 'gdb plugin [pid]'. In gdb break on 'WebKit::NetscapePlugin::initialize(WebKit::PluginController*, WebKit::Plugin::Parameters const&)' and then enter 'continue'.
Updated•13 years ago
|
Summary: Large pauses when loading https://github.com/graydon/rust/commits/master → 3-4 seconds delay loading pages with many (30+) Flash plugins
Updated•13 years ago
|
Summary: 3-4 seconds delay loading pages with many (30+) Flash plugins → 3-4 seconds delay loading page with many (30+) Flash plugins
Reporter | ||
Comment 9•12 years ago
|
||
We also spend a bunch of time waiting in mozilla::plugins::PluginModuleParent::NPP_NewStream
Comment 10•12 years ago
|
||
I've been seeing this bug when loading http://boingboing.net recently.
Updated•12 years ago
|
Whiteboard: [SPS][Snappy] → [SPS][Snappy:P1][telemetry-needed]
Comment 11•12 years ago
|
||
So here's a patch for telemetry in the functions Jeff was timing. Josh f-'d a similar patch for just the shutdown case in bug 706647, though, with concerns that we'd be counting time when the plugin host decided to delay shutdown or we had already started destroying the plugin. But at least the startup bits of this patch might be worthwhile.
Comment 12•12 years ago
|
||
Comment on attachment 601368 [details] [diff] [review] patch to add telemetry timers Having telemetry probes *somewhere* in the plugin bits would be good; might as well start here.
Attachment #601368 -
Flags: feedback?(joshmoz)
Comment 13•12 years ago
|
||
Comment on attachment 601368 [details] [diff] [review] patch to add telemetry timers Josh approved a partial patch in bug 706647; I'll update this one to just do plugin startup tomorrow.
Attachment #601368 -
Flags: feedback?(joshmoz)
Comment 14•7 years ago
|
||
Resolving old bugs which are likely not relevant any more, since NPAPI plugins are deprecated.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INCOMPLETE
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•