Closed
Bug 567124
Opened 14 years ago
Closed 11 years ago
Firefox 3.6.3 has far worse Flash performance than 3.5.9
Categories
(Core Graveyard :: Plug-ins, defect)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: vadimrapp, Unassigned)
References
()
Details
(Keywords: flashplayer, perf)
Attachments
(3 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100315 Firefox/3.5.9 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100315 Firefox/3.5.9 I uploaded youtube video (see the URL) that shows how performance of Flash 10.0.45.2 significantly drops with the upgrade from Firefox 3.5.9 to 3.6.3 . The testing was made at website en.dinoparc.com, which is flash game. You can see how after the upgrade from 3.5.9 to 3.6.3 rendering of every page takes several times more time. Reproducible: Always Steps to Reproduce: 1. sign up and play the game at en.dinoparc.com in FF 3.5.9 / flash 10.0.45.2 2. upgrade FF to 3.6.3 3. see how performance drops.
Reporter | ||
Updated•14 years ago
|
Keywords: flashplayer,
perf
Version: unspecified → 3.6 Branch
Comment 1•14 years ago
|
||
Please retest with the 3.6.4 beta or a nightly trunk build.
Reporter | ||
Comment 2•14 years ago
|
||
Tried in 3.6.4 and in nightly build - no change from 3.6.3. In 3.5.9 and in IE8, the first navigation to the page with animation takes longer time, but all subsequent are instant; in FF 3.5.9 this effect survives browser restart. In 3.6.3 and later, each navigation takes the same time as the first in 3.5.9 - so it looks like some caching isn't working.
Updated•14 years ago
|
Component: General → Plug-ins
Product: Firefox → Core
QA Contact: general → plugins
Version: 3.6 Branch → 1.9.2 Branch
Comment 3•14 years ago
|
||
Vadim, would you mind attaching HTTP logs of both 3.5.9 and 3.6.3 doing whatever task it is that shows slowness in 3.6.3 but not 3.5.9? See https://developer.mozilla.org/en/HTTP_Logging for the directions on getting those.
Reporter | ||
Comment 4•14 years ago
|
||
Reporter | ||
Comment 5•14 years ago
|
||
Reporter | ||
Comment 6•14 years ago
|
||
Done. Wondering why the log created by 3.6.3 is ~five times larger.
Updated•14 years ago
|
Attachment #446806 -
Attachment mime type: application/octet-stream → application/zip
Comment 7•14 years ago
|
||
> Wondering why the log created by 3.6.3 is ~five times larger. Well, each data packet received tends to get logged, so if you're hitting the network more.... Here's one obvious difference between the logs. 3.5.9: 0[826140]: uri=http://en.dinoparc.com/swf/dino.swf?$version=1 .... 0[826140]: nsHttpResponseHead::MustValidate ?? 0[826140]: no mandatory validation requirement 0[826140]: Not validating based on expiration time 0[826140]: CheckCache [this=54cfd50 doValidation=0] 3.6.3: 0[826140]: uri=http://en.dinoparc.com/swf/dino.swf?$version=1 .... 0[826140]: nsHttpResponseHead::MustValidate ?? 0[826140]: no mandatory validation requirement 0[826140]: Validating based on RFC 2616 section 13.9 (query-url w/o explicit expiration-time) 0[826140]: nsHTTPChannel::CheckCache exit [this=1754870 doValidation=1] This was a change made in bug 468594. The comment explaining what's going on with that change is: + // RFC 2616, section 13.9 states that GET-requests with a query-url + // MUST NOT be treated as fresh unless the server explicitly provides + // an expiration-time in the response. Now in this case the GET does have a query part, and the HTTP response looks like this: 1732[8263c0]: http response [ 1732[8263c0]: HTTP/1.1 200 OK 1732[8263c0]: Via: 1.1 VPSISPS 1732[8263c0]: Connection: Keep-Alive 1732[8263c0]: Proxy-Connection: Keep-Alive 1732[8263c0]: Content-Length: 816156 1732[8263c0]: Date: Fri, 21 May 2010 21:18:29 GMT 1732[8263c0]: Content-Type: application/x-shockwave-flash 1732[8263c0]: Etag: "48407d-c741c-43b70d70" 1732[8263c0]: Server: Apache/1.3.41 (Unix) PHP/5.0.4 mod_deflate/1.0.21 1732[8263c0]: X-Real-Server: gimme1.motion-twin.com 1732[8263c0]: Last-Modified: Sat, 31 Dec 2005 23:00:00 GMT 1732[8263c0]: Accept-Ranges: bytes 1732[8263c0]: Keep-Alive: timeout=1, max=95 1732[8263c0]: ] There is no Expires or Max-Age header, so the response can't be assumed to be fresh per the above RFC. Firefox 3.5.9 got this wrong and basically assumed that the response is fresh no matter what. Now if the response isn't fresh, we have to do a GET to the server. So we do: 0[826140]: http request [ 0[826140]: GET http://en.dinoparc.com/swf/dino.swf?$version=1 HTTP/1.1 0[826140]: Host: en.dinoparc.com 0[826140]: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 0[826140]: Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 0[826140]: Accept-Language: en-us,en;q=0.5 0[826140]: Accept-Encoding: gzip,deflate 0[826140]: Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 0[826140]: Keep-Alive: 115 0[826140]: Proxy-Connection: keep-alive 0[826140]: Cookie: block_dinozListBlock=inline; sid=KYDUHQSQb4CnBiXlLMcDmMQSAkdBgZNe 0[826140]: If-Modified-Since: Sat, 31 Dec 2005 23:00:00 GMT 0[826140]: If-None-Match: "48407d-c741c-43b70d70" 0[826140]: ] The server can now either respond with "nope, hasn't changed from the version you have cached; use the cached version" (HTTP 206 response) or send back the data all over again (HTTP 200 response). This server does the latter. So we end up redownloading this 816KB swf file over and over again, because the server keeps claiming it has changed. Similar for the 500KB http://en.dinoparc.com/swf/map.swf?$version=1 Unfortunately, this looks like a bug in the site (not sending HTTP 206 when it really should). A bug in Firefox 3.5.9 which caused it to not check with the server at all in situations where it's required papered over this problem, but that bug was fixed in Firefox 3.6.
Reporter | ||
Comment 8•14 years ago
|
||
Boris, thanks for your thorough explanation, I forwarded it to the developers of this site. If you don't mind, still, - I'm curious why this effect does not show up in IE8. I have attached HTTP log (obtained using Proxomitron) of IE8 subsequent request, when the animation already shows up instantly. As you can see, the response to the initial request , +++RESP 523+++ , has Cache-Control: no-cache, must-revalidate . which, if I understand correctly, means that the browser has to revalidate all objects on the page, including two swf's - which is what FF does. But IE8 does not request the .swf's. Why?
Comment 9•14 years ago
|
||
> But IE8 does not request the .swf's. Why? I don't know... As far as I know, IE generally makes a conditional requests for such requests (and in fact doesn't even store no-cache stuff in its cache at all; see http://blogs.msdn.com/b/ie/archive/2010/07/14/caching-improvements-in-internet-explorer-9.aspx ).
Comment 10•11 years ago
|
||
reporter do you still see this problem when using newer version of flash, and current version of firefox?
Whiteboard: [closeme 2013-04-11]
Reporter | ||
Comment 11•11 years ago
|
||
Hard to tell compared to Firefox 3.5.9, but I just compared it to IE8 and to Chrome. Unlike them, FF refreshes the whole page, while they refresh only the changing part of it, and yes, because of that it's somewhat slower.
Comment 12•11 years ago
|
||
Resolved per whiteboard
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → INCOMPLETE
Whiteboard: [closeme 2013-04-11]
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
•