InformAction Forums

The cycle collector and the garbage collector aren't separate before Firefox 4?

dhouwn wrote:The cycle collector and the garbage collector aren't separate before Firefox 4?

I'm not very deep into this subject, but I based my conjecture on the observation that, under our stress conditions, Components.utils.forceGC() (which triggers exclusively the JavaScript GC) takes about 10 times less than nsIDOMWindowUtils.garbageCollect() (which involves the cycle colector).
This is true on both Fx 3.6.x and Fx 4.

I didn't do this because of NoScript, but it kind of applies here too...

-------

<therube> my apples & oranges SM20/SM21 Mem Usage of yesterday ...
<therube> today trying with new Profile, sandboxed (sandboxie), but not progressing very well.
<therube> this is using existing sessionrestore.json (only) from existing 21 Profile.

<therube> SM20 #1, crashed at 1:37.
<therube> SM20 #2, got a lot further, 10:26 before crashing, & was using 2.14 GB of Mem at the time.
<therube> http://i55.tinypic.com/2aaftau.jpg

<therube> SM21, I crash at about 1:40 on 3 consecutive tries, each time Mem Usage was past 2.40 GB.

<therube> with NoScript (blocking JavaScript) I can load (as it is the same session restore that i *do* load on startup).

<therube> with BarTab (blocking <most of> background tabs, per Window), I would expect that I could load successfully too (though i haven't tried...)

<therube> SM20, i had not completed loaded in run #2, though i /suspect/ that within a couple more minutes i would have completely loaded?
<therube> SM21, i was nowhere near finished loading.

...vvv... added NoScript extension ...vvv...

<therube> SM20, with NoScript, Mem Usage 1.80 GB, completely loading in 2:03, & working & usable.
<therube> http://i51.tinypic.com/2hg8pkk.jpg

<therube> SM21, with NoScript, Mem Usage 2.1 GB, loaded in 5:00. for whatever reason it took till then for network activity & CPU usage to quiet
<therube> down. Working, though seems "heavier".
<therube> http://i55.tinypic.com/dmcrys.jpg


<KaiRo> therube: before I leave - 2.1 takes longer because we have delayed session restore, i.e. we only load a small number of tabs insteantly, and load the others with delays
<therube> KaiRo: is that in 2.1b2 ?
<KaiRo> yes
<therube> & yet without NoScript, I crashed 3x in a row?


crash report numbers to follow....:


SM20 01:37 https://crash-stats.mozilla.com/report/ ... 6032110311
SM20 10:26 https://crash-stats.mozilla.com/report/ ... f5e2110311

SM21 #1 https://crash-stats.mozilla.com/report/ ... d852110311
SM21 #2 https://crash-stats.mozilla.com/report/ ... 9ba2110311
SM21 #3 https://crash-stats.mozilla.com/report/ ... 9d62110311



<therube> had a thought ... add BarTab extn
<therube> well i better stop thinking.
<therube> adding BarTab extension to SM21 reduced the "load" time, time till network activity stopped, to ... to ... less then 40 seconds (from 5:00 minutes without).
<therube> i was up & loaded before i finished my thoughts to post here.
<therube> (this is with both NoScript & BarTab installed)
<therube> don't really know how much content is actually blocked by BarTab, but in my book, it is AWESOME!

<therube> so SM20 i was >10 minutes, never finished loading & crashed. SM21 crashed at ~1.40 consistently. NoScript reduced 20's load to to 2 minutes & 21's load to 5 minutes. Adding BarTab to 21 reduced it's load to < 1 minute, using 1.25 GB ram. Adding BarTab to SM20, load in 30 seconds & using 900 MB ram.


Bug 641164 - sessionrestore crash on startup

Just a quick report that I have also noticed same performance problems with noscript on winxp, p4 laptop ff 3.6. Noticably sluggish browsing and occasional lock ups requiring restart. Unfornately had to disable the plugin on latop which returns it to comfortable stable browsing. Hope a fix will be possible. Regards.

Could you check latest development build? Thank you.

Giorgio Maone wrote:Could you check latest development build? Thank you.

I'll try and 4.0 as well. It looks like you went back to the original method in ScriptSurrogate.execute, without any settings? Did it turn out to be better in all circumstances?

al_9x wrote:

Giorgio Maone wrote:Could you check latest development build? Thank you.

I'll try and 4.0 as well. It looks like you went back to the original method in ScriptSurrogate.execute, without any settings? Did it turn out to be better in all circumstances?

I'm using it for page surrogates only.
The main drawback was that this way they run asynchronously, but apparently the time I'm executing them now (on window creation, before documentElement has been created) is early enough to ensure they run before any other script, even though they're not synchronous.
Inclusion surrogates are being run through DOM manipulation.

On Firefox 4, just removing the sandbox-based surrogate execution method allowed to reduce memory usage (and thus performance hit due to memory alocation, fragmentation and garbage collection) by half in the 50 CNN tabs test!
Looks like memory management in presence of sandboxes needs a lot of love from moz devs...

There's some improvement, 10 m, but not close to 2.0.1, 3m40s.

al_9x wrote:There's some improvement, 10 m, but not close to 2.0.1, 3m40s.

Notice that, beside the different system to run surrogates, 2.0.6 and above have quite an expensive additional surrogate running in your configuration (plugin lockdown on trusted pages), i.e. the liveconnect interception one. What does happen if you turn it off in [url=http://kb..org/About:config]about:config[/url]?

There is no "my configuration" all my tests are run in a new profile with default settings, however I did forget one thing, to disable all plugins (in Fx, as per original test params), but it was still apples to apples, since I ran both 2.0.1 and 2.1.0 with plugins enabled. Nevertheless, I'll retest.

Remember, the time jumped from 3:40 to 12:10 between 2.0.1 and 2.0.2. From then to 2.0.7/8/9 it got only slightly worse: 12:30, statistically not very significant. The only changes that really matter are between 2.0.1 and 2.0.2. If you return the 2.0.1 surrogate technique, should it not come down to ~ 3:40?

Fx 3.6.16, new profile, all plugins disabled, default ns settings

1. 2.0.1 - 3:20
2. 2.0.9 - 11:45
3. 2.1.0rc3 - 8:15

Please check latest development build, thanks.

I discovered "windowshopper" spyware got into my ff via "Ietab plus", and it was trying to contact superfish.com lots. I reactivated noscript after removing the spyware and performance is returned to normal -it may have been having to fight with the scripts before. In noscript options i had 'show message about blocked scripts' unchecked, which ive checked now to hopefuly alert such situations in the future. Thanks.

Giorgio Maone wrote:Please check latest development build, thanks.

2.1.0rc5 - 3:45, thanks, the subsequent long locking spikes are also reduced/eliminated.

Fx 4.0.0 is looking better:

without NS - 1:55
2.1.0rc5 - 2:55

I noticed a few surrogate regressions, you probably have a surrogate test suite to catch more?

1. !@ - is not running with script off
2. on the hotmail https inbox page, default.aspx, the @!* surrogate runs on 5 frames (including root) in 2.0.9.9:
   1. default.aspx
   2. InboxLight.aspx
   3. HistoryFrame.aspx
   4. 1st ad iframe: adloader.html
   5. 2nd ad iframe: adloader.html
   and only on the root (default.aspx) in 2.1.0rc5
3. tried @* while at it. In 2.0.9.9 it runs on the first three, not on the ad frames. Presumably that's a bug, should it run on all 5? In 2.1.0rc5 it runs on the same three frames but the surrogate dumps out 'about:blank' for document.URL of InboxLight.aspx and HistoryFrame.aspx. Is that a sign of a problem?