555500 - [OOPP] Silverlight plugin takes 6x longer to load with IPC plugins than without

Status: RESOLVED WORKSFORME

(Core :: IPC, defect)

Description

[IU]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a4pre) Gecko/20100327 Firefox/3.5.8 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a4pre) Gecko/20100327 Minefield/3.7a4pre ID:20100327035846

Turns out the patch from Bug 547359 far from adequately addresses this Silverlight plugin relate performance issue.  The linked page shows that the issue is much much worse:

With IPC plugins enabled, the CTV Olympics video takes about 11 times longer to load than with IPC plugins disabled (8 seconds vs. 126 seconds) on my P3 system.

Hopefully video access is not geographically restricted, so you'll be able to test it.  I am also attaching an IPC plugins log.


Reproducible: Always

Steps to Reproduce:
1. With IPC plugins enabled, visit the linked URL and time how long it takes
for the CTV Olympics video player to load (pretty much when the red "O" starts spinning
2. Disable IPC plugins, restart the browser, and test again
3. Notice the significant performance difference.

Comment 1

[IU]

Attachment: IPC plugins log (loading http://www.ctvolympics.ca/video/index.html)

Comment 2

[IU]

For comparison purposes, I've just timed Chrome 5 and it take just as long (about 121 sec).  So could the problem has do with the latency of all that RPC communications?

Would it be possible to determine whether video/audio is ready to for display and output and if not, Firefox switches to a burst mode and allows data to sent in large chucks, without having to do so much back-and-forth?  Once data is ready to be output (video/audio), Firefox switches burst mode off.

Just trowing out an idea.  Not sure if I'm out to lunch. :-)

Comment 3

[IU]

*sigh* I really should proofread.

Comment 4

[Ben Turner (not reading bugmail, use the needinfo flag!)]

This log shows a bunch of identifier churn but it doesn't result in any IPC calls. All the churn is happening in the child exclusively.

Comment 5

[IU]

So is there a way to optimize it?  Maybe suppress all that churning?  I would imagine much of that is unnecessary, considering it takes only 8 seconds to load when IPC is disabled.  And because of all that churning, there's such a huge impact on performance.

Comment 6

[Ben Turner (not reading bugmail, use the needinfo flag!)]

I don't think there's anything further we can do with identifiers, no. I just filed bug 556849 and it may make things better, though.

Comment 7

[IU]

Thanks, Ben.  I'll check things out once bug 556849 lands and then close this, as necessary.

Comment 8

[IU]

Well, my math in my initial report was obviously wrong (should have been 15.8X slower).  Not sure what I did there. :-)

With bug 556849 landed, there's a lot of improvement (now down to about 5.7X slower).  Times are not directly comparable, because something has recently regressed performance somewhere.  Anyhow, I now get 9.6 seconds vs about 55 seconds.  Still a comparatively long time to wait.

Would that be about the most that can be squeezed out?

Comment 9

[Kevin Brosnan]

URL is dead, maybe http://www.silverlight.net/learn/videos/silverlight-4-videos/ can be used as a substitute?

Comment 10

[IU]

From limited testing, this appears to no longer be an issue -- at least not with current nightly m-c builds.

Checked using: http://hg.mozilla.org/mozilla-central/rev/d8ca3e1c469e