User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124) Gecko/20100315 Firefox/3.5.9 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199) 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.
Keywords: flashplayer, perf
Version: unspecified → 3.6 Branch
Please retest with the 3.6.4 beta or a nightly trunk build.
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.
Component: General → Plug-ins
Product: Firefox → Core
QA Contact: general → plugins
Version: 3.6 Branch → 1.9.2 Branch
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.
Done. Wondering why the log created by 3.6.3 is ~five times larger.
Attachment #446806 - Attachment mime type: application/octet-stream → application/zip
> 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: uri=http://en.dinoparc.com/swf/dino.swf?$version=1 .... 0: nsHttpResponseHead::MustValidate ?? 0: no mandatory validation requirement 0: Not validating based on expiration time 0: CheckCache [this=54cfd50 doValidation=0] 3.6.3: 0: uri=http://en.dinoparc.com/swf/dino.swf?$version=1 .... 0: nsHttpResponseHead::MustValidate ?? 0: no mandatory validation requirement 0: Validating based on RFC 2616 section 13.9 (query-url w/o explicit expiration-time) 0: 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: http request [ 0: GET http://en.dinoparc.com/swf/dino.swf?$version=1 HTTP/1.1 0: Host: en.dinoparc.com 0: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52) Gecko/20100401 Firefox/3.6.3 0: Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 0: Accept-Language: en-us,en;q=0.5 0: Accept-Encoding: gzip,deflate 0: Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 0: Keep-Alive: 115 0: Proxy-Connection: keep-alive 0: Cookie: block_dinozListBlock=inline; sid=KYDUHQSQb4CnBiXlLMcDmMQSAkdBgZNe 0: If-Modified-Since: Sat, 31 Dec 2005 23:00:00 GMT 0: If-None-Match: "48407d-c741c-43b70d70" 0: ] 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.
Created attachment 446897 [details] HTTP log of IE8 requesting this page 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?
> 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 ).
reporter do you still see this problem when using newer version of flash, and current version of firefox?
Whiteboard: [closeme 2013-04-11]
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.
Resolved per whiteboard
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INCOMPLETE
Whiteboard: [closeme 2013-04-11]
You need to log in before you can comment on or make changes to this bug.