416873 - Performance issue happens between NPP_NewStream and NPP_WriteReady when time between them increases

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Plug-ins, defect)

Description

[John Chen]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11

The leak starts on 10-15 minutes. The blue square on the screen with tween makes it easy to see the leak (the square starts jumping instead of moving smooth once the leak starts). The number on the screen represents the xml connections completed. I have tested on a few computers, the problem starts after 800-1000 connections usually. 

Reproducible: Always

Steps to Reproduce:
1) go to http://scbos.gm-project.com/xmltester.html
2) stare at blue square until lag appears
Actual Results:  
Blue square skips frames/performance issue

Expected Results:  
blue square to move smoothly

[johnchen 12/21/07] bug confirmed on Firefox and 9r115 and 10.347 . Happens on PC and MAC. After about 800- 1000 iterations, the square starts to chug. It also lags the computer. However I ran it simultaneously on IE and Firefox but IE blue square is still smooth. on MAC, Safari 3 ran smoothly while Firefox 2 started to chug after awhile.

Possible Firefox issue. Attached source file .fla
[cmckeon 12/21/07] John - can you review the code to look for bad code - and run it in the memory profiler.
[johnchen 12/21/07] the code looks clean. There is no memory leak; they stayed the same. This is more of a performance issue. The strange thing is that the cpu usage increases only slighty for Firefox: from 10% to 14% while safari stays at 5.7%. Performance issues usually take up more cpu.

The performance issue is much more apparent on a Windows system. To see it on the MAC, wait until the iteration reach 1000, then drag the browser window around; it will chug every 1 second (draging Safari browser around is smooth and constant)
[johnchen 12/21/07] after iterating 4500 times, the cpu % went up to 48% for Firefox, and Safari stayed at 4.7%. Memory usage stayed the same. Running on a pretty fast system: 2x2.66 Dual core intel xeon 2 gb memory, MACOSx 10.4.10.

This is a serious issue for networking Flash games; on Firefox only.
[lthomaso 1/7/08] QRB opening
[magnus 1/18/08] Memory leaks on Windows Firefox as well.
[magnus 1/18/08] no leaks afterall.
[magnus 1/25/08] ran Visual Studio 2008 profiler on IE and Firefox. The CPU usage in Firefox happens mostly in the browser itself, not the flash player plugin it seems like. Where the CPU usage in IE and the plugin (Flash.ocx) are about the same. Here are the results:

IE =
Name Inclusive Samples
-----------------------------------------
IEFRAME.dll 2,917
USER32.dll 2,869
Flash.ocx 2,404


Firefox=
Name Inclusive Samples
-----------------------------------------
firefox.exe 21,898
xpcom_core.dll 21,510
USER32.dll 21,325
ntdll.dll 13,293
kernel32.dll 13,217
NPSWF32.dll 2,440

[magnus 1/25/08] Converted the test SWF from AS2 to AS3. Same problem occurs.

Modified swf that once it reaches 1500 iterations, it stops loading the XML. So after 1500 iterations, performance is back to normal.
[magnus 1/30/08] The issue does not involve XML, but involves Loader.load(new URLRequest(-url-)) in AS3 rapidly. The chug happens when -url- is different for every load because with the same -url-, Firefox caches its data. Seems like a Firefox issue when processing the different URL requests, which causes Firefox to unable to render flash player's screen quick enough.

[magnus 1/31/08]

I can confirm that this is a Firefox bug (more specifically a NPAPI bug since it happens on Opera and Safari as well)

The chug happens between NPP_NewStream and NPP_WriteReady. We do not see the chug initially because the time between NewStream and WriteReady is very short. After awhile, the time between NewStream and WriteReady grows larger, therefore we see the chugs.

I even added a NOop loop in NPP_NewStream to reproduce the chug and it behaved like running the swf after many iterations.

Between NewStream and WriteReady, the CPU % increases about 10% during that time.

Here's the output from VS2008 when rapidly calling Loader.load() after a few iterations and after many iterations (same output between the two):
==============================================================================
Constructor PlatformURLStream ...... this = 6c44028
End of ProcessQueue
CorePlayer::UpdateScreen
CorePlayer::UpdateScreen
CorePlayer::UpdateScreen
CorePlayer::UpdateScreen
CorePlayer::UpdateScreen
CorePlayer::UpdateScreen
CorePlayer::UpdateScreen
NPP_NewStream
window.location is file:///C:/download/xmlLeak/xmlTestAS3.swf
end of NPP_NewStream
<---------------** Chug happens here! FP waiting for browser, no UpdateScreen **----------------->
NPP_WriteReady
NPP_Write
NPP_DestroyStream
reason of URLNotify for url http://scbos.gm-project.com/srv/xmltest.asp?beybi=1072 : 0
DESTRUCTOR: PlatformURLStream ...... this = 6c44028
==============================================================================

Summary:
Not a FlashPlayer bug because:
1. Time between NPP_NewStream and NPP_WriteReady is large after many iterations.
Flash is waiting between that time period and cannot update the screen,
therefore we see the chug.
2. CPU cycles between NPP_NewStream and NPP_WriteReady increases about 10% avg.
3. Ran VS2008 profiler, most CPU cycles in Firefox.exe, not in NPSWF32.dll.

Comment 1

[Johnny Stenback (:jst)]

Not going to block on this unless there's concrete evidence showing this causing significant problems on real websites.

Comment 2

[John Chen]

This affects very few online multiplayer Flash games.  This will probably come up more often when more online games are released