InformAction Forums

Still disabled ...

Opening yet another 50 cnn.com tabs, & still I'm running acceptably. Have at least two Flash clips running in tandem. CPU is not bonking. Tabs open OK, (OK enough) ... (Oh & I have MANY plugin container <Flash> crashes, which is probably to be expected?)


Let me restart with NoScript re-enabled ...

al_9x wrote:Furthermore, it appears to take considerably longer to load the 50 tabs (from bookmarklet execution to cpu subsiding) with NS, than without. I'll time it and post the results.

XP32SP3, Fx 3.6.14, NS 2.0.9.9rc4, new profile, all plugins disabled

time to load 50 cnn tabs (with cnn already cached)

without NS: 2 minutes 15 seconds
with NS:12 minutes

That's horrible. Girorgio, please don't drop this .

Some 15 minutes or so later, & I wasn't really watching it, but only observing CPU usage & it never dropped to where I thought FF had finished loading, but on bringing FF to focus, it crashed (Mozilla Crash Reporter) & separately Plugin Container crashed (Windows saying that).

Should note, that on this start, NoScript was (still in) Allow Global. Thinking that once I can shut down again (or crash again) & Revoke all, that FF will start & react fairly well?

@therube you are introducing too many variables and reporting too many useless details, please conduct the experiment as defined by the author: Fx 3.6.14, NS 2.0.9.9rc4, new profile, default Fx and NS settings, all plugins disabled. And post just the results.

Perhaps so, but I don't think it will make a difference.

Knowing it's going to take a LONG time before I get any kind of response, I killed FF.
Restarted.
That brought up about:sessionrestore asking if I wanted to restore or start anew.

That dialog also presented the NoScript icon, showing as Allow Globally, which allowed me to Forbid Script Globally, & only after that, I continued with the session restore dialog, telling it to reopen all my tabs. And it is now open - speedily, with no CPU bumps, reacting normally.

> 1. I used Firefox 3.6.14 (Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.14) Gecko/20110218 Firefox/3.6.14).

Ditto.

> 2. I created a new profile.

Ditto.

> 3. I disabled all extensions and plugins.

No extensions, no nothing.

>>>> 4. I installed NS 2.0.9.8.

Not yet.

> 5. I opened 50 tabs of cnn.com by executing the following in the address bar of the first tab (which had the Mozilla Firefox start page):
Ditto.
Time to open, network indicator activity shows no activity, & CPU usage dropped to nil ... 1 min 15 sec.

> 4. I installed NS 2.0.9.8.

Quit, not saving session.
Restart.
Notified that NS 2.0.9.8 is installed.
Quit, not saving session.
Restart.

> 5. I opened 50 tabs of cnn.com by executing the following in the address bar of the first tab (which had the Mozilla Firefox start page):

Ditto.
Time to open, network indicator activity shows no activity, & CPU usage dropped to nil ... 20 sec.


Let me Quit, restart, this time from Session Restore ...
Time to open, network indicator activity shows no activity, & CPU usage dropped to nil ... 20 sec. (being generous).


Let me Quit, restart, not from session restore, open 1 cnn.com page, Allow cnn.com, then proceed to open 50 more pages ...
Time to open, network indicator activity shows no activity, & CPU usage dropped to nil ... 4 min 5 sec.


I (attempt) to give FF focus, & CPU jumps. Back off (here) CPU resides. I see that, jump back & open 1 page, then back here. CPU resides. And while here, I see CPU jump again. Open another tab, & before I can click the link, CPU jumps. So I jump back here. Resides. Jump back to FF, but focus is not given. CPU jumps. Catch it at the right moment, being quick about it, I happen to be able to click to 4 tabs, opening a link from each, in quick succession, but then CPU jumps ...


> The problematic behavior is not the same as in my original post, but there is definitely a significant performance impact,
> and it makes FF unusable even in the relatively modest use case of 50 instances of cnn.com. Can anyone confirm?

Yes.

I have seen behavior like this in the past. Not always, but from time to time. Never thought to attribute it to NoScript (or any extension), thinking that it was just the browser & plugins being caught in some kind of loop. Have even chatted about it (in #seamonkey) chronicling what was happening, that I was looping, that I knew eventually I was going to crash, that either I shut down & restart, or just wait for the inevitable crash. One or the other would happen.

I'll give you FF's crash (from earlier) - if I can get it shut down ...

Well they don't look like they're going to do much good:
They're not giving up information. (Crash reporter is/has been buggered.)


Thanks miroslav.policki .

buggered

Worthless.

OOID not found: a4330690-e14a-4ae1-b57c-d80af2110301 - a110301a4330690-e14a-4ae1-b57c-d80af2110301
OOID not found: ef71a738-dc36-4c01-a7ec-0b1a72110301 - e110301ef71a738-dc36-4c01-a7ec-0b1a72110301
/data/socorro/stackwalk/bin/stackwalk.sh returned no header lines for reportid: 225470616; No thread was identified as the cause of the crash; No signature could be created because we do not know which thread crashed; /data/socorro/stackwalk/bin/stackwalk.sh returned no frame lines for reportid: 225470616; /data/socorro/stackwalk/bin/stackwalk.sh failed with return code 1 when processing dump bec0786f-dfff-402e-90c7-0dfff2110301

Kairo is now doing some work on Crash Reporter (Socorro). Maybe he'll get them straightened out .

I did another trial, this time in a clean xp sp3 vm. With similar results.
Loading of 50 cnn (cached) tabs:

without NS: 3 min 10 sec
with NS: 19 min 30 sec and subsequent cpu lockups

this time, somewhere in the middle of the NS run there was an unresponsive script warning for RequestWatchdog.js:914 (the messagebox text failed to copy, so 914 is from memory, I ran it again to double check the message but there was no warning and it completed in 18 minutes)

Another thing worth pointing out is that cnn.com is forbidden by default, so without NS there is a lot more content script loading and executing, so one hopes that loading with NS would be faster, instead it's 6 times slower, but the main problem is what happens after.

al_9x wrote: Another thing worth pointing out is that cnn.com is forbidden by default, so without NS there is a lot more content script loading and executing, so one hopes that loading with NS would be faster

In fact, it is more than 4 times faster in my tests.

I've run two iterations for each profile:

• Empty cache, run the scriptlet, wait for all the 50 tabs to be completely loaded
• Open a new window, close the first window, wait for the memory to be released
• Rerun the scriptlet (cache should be used)
• Exit the browser

System: Win XP 64 SP2, CPU Q6600 @ 2.40Ghz, 8GB RAM.

1. Fx 3.6.14 clean profile, no extensions:
   
   
   
   65 seconds first ran, 75 seconds second run: looks like having most stuff cached is trumped by more memory pressure.
   Notice also the RAM usage peak at 405MB.
2. Fx 3.6.14 clean profile + NoScript 2.9.9.9rc4 default options
   
   
   Unsurprisingly, my results are in line with therube's: having NoScript enabled and blocking most requests improves performance up to 470%.
   Furthermore, the peak in RAM usage is at 187MB, which is abundantly less than half the consumption measured on vanilla Firefox.

Switching to "Allow scripts globally" is a completely different beast, and I do expect page loadings to be somewhat slower than vanilla Firefox: don't forget most requests are checked at least at 2 different levels, sometimes at 3:

1. XSS (cross-site top level documents and frames only)
2. Content policies (every single request)
3. ABE (every single request)

I'm gonna test this scenario and figure out what in this specific case makes more difference in the next few days (I need to have the second iteration of NSA out before Friday), but I don't expect such a synthetic scenario to be indicative of any serious performance problem in real world usage.

Furthermore, the spikes which are observed during the browsing with these 50 tabs open are most likely due to these pages refreshing themselves automatically through timed <META> refreshes, thus causing the whole request check chain to be triggered each time, possibly in sync for multiple tabs.

[EDIT]
I don't want to underestimate this report, which may really help at optimizing page loads under stress conditions, nor I'm saying al9_x's results are bogus: IIRC, al9_x's CPU is very underpowered, so the main suspect for his results is the XSS filter, which is very CPU intensive if compared with all the other components of a "normal" request processing flow. However, it should be noticed that my CPU is not exceedingly fast or modern if compared with current off-the-shelf hardware, especially if we consider that current Firefox version don't take much advantage of multiple cores.

About the cpu, yes my p4 3 ghz is old, but it's good enough for gpu unaccelerated 1080p h264 playback, so shouldn't it be good enough to browse the web with ns? I have noticed that it is actually faster than a modern 1.6ghz Atom, and this test also confirms it. On an atom netbook the CNNx50 took 20 minutes with NS and 4 minutes without. What do you think is a more common web machine globally, a $200 atom netbook or a $1000-$1500 quadcore tower? Are you ready to abandon this class of user with the "it works on my dev machine" response? If not, then would you like to see it for yourself?

Furthermore, the spikes which are observed during the browsing with these 50 tabs open are most likely due to these pages refreshing themselves automatically through timed <META> refreshes, thus causing the whole request check chain to be triggered each time, possibly in sync for multiple tabs.

That's not the case, the meta refresh on cnn is set to 30 minutes, it's not refreshing yet.

al_9x wrote:About the cpu, yes my p4 3 ghz is old, but it's good enough for gpu unaccelerated 1080p h264 playback, so shouldn't it be good enough to browse the web with ns? I have noticed that it is actually faster than a modern 1.6ghz Atom, and this test also confirms it. On an atom netbook the CNNx50 took 20 minutes with NS and 4 minutes without.

But isn't normal browsing more than usable, instead?

al_9x wrote: What do you think is a more common web machine globally, a $200 atom netbook or a $1000-$1500 quadcore tower? Are you ready to abandon this class of user with the "it works on my dev machine" response? If not, then would you like to see it for yourself?

As I said, I'm gonna investigate ways to alleviate this edge case on slow machines, it's just not a priority (this week at least) because we lived just well so far, and there are machines (mine an therube's, for instance) where even this absolutely artificial test (which, for instance, completely locks the cache because all the loads try to acquire the same lock at the same time) is 3 or 4 times faster with NoScript than without it.

al_9x wrote:

Furthermore, the spikes which are observed during the browsing with these 50 tabs open are most likely due to these pages refreshing themselves automatically through timed <META> refreshes, thus causing the whole request check chain to be triggered each time, possibly in sync for multiple tabs.

That's not the case, the meta refresh on cnn is set to 30 minutes, it's not refreshing yet.

If it's not the <META>, it may very well be a JavaScript or a Flash reload, but if you look closely you'll notice that every page there reloads itself just after being loaded the first time.

Intel i5-750, so no powerhoruse, but far more modern then I'm used to.

Unsurprisingly, my results are in line with therube's: having NoScript enabled and blocking most requests

Quite.

It was not until I Allowed CNN, then loaded the 50 that my times increased - markedly.
And when I set Allow Globally, then times went through the roof.

Furthermore, the spikes which are observed during the browsing with these 50 tabs open are most likely due to these pages refreshing themselves

Not IMO. When I generated the looping situation, it was most likely not page refreshes.

absolutely artificial test ... But isn't normal browsing more than usable, instead?

But is it, necessarily? If you take into consideration a start from Session Restore, that act of restoring is kind of abnormal in itself. If you have LOTS of windows, LOTS of tabs (as I most often do), Session Restore opens/loads the whole shebang in a quasi-concurrent way. Theoretically, with NoScript enabled & not many domains Allowed, the restore should proceed faster then if NoScript was not installed. And also theoretically if you happened to be a user who had many Trusted sites, Allowed, (& you would think that as Trusted many sites, they would apt to be ones you may be opening in a restore), NoScript could be detrimental to restore times. And if you were a user who defaulted to Allow Globally, you would expect restore times to go through the roof, theoretically. (Theoretically as it is only conjecture at this point.)

I generally only ever Temporarily Allow, so if I close my browser, then restore sometime later, one would expect that NoScript would be of benefit to me because upon on restart, all the Temporarily Allowed sites are defaulted back to Not Allowed, & should lessen load & memory times. Even so, with the number of windows/tabs I restore, it was still a time consuming ordeal. (Now that I use BarTab, loads from Session Restore are no longer an issue.)


"Normal" page loads should be less affected, if you want to look at it like that. Does an Allow still by default refresh all affected pages in the domain? If you had 10 pages of a site open, & then realized you need to Allow, you would be refreshing 10 pages (perhaps not full refreshes, necessarily). Could become more time consuming at that point?

miroslav.policki wrote:Ok, I have a test case.
1. I used Firefox 3.6.14 (Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.14) Gecko/20110218 Firefox/3.6.14).

I wonder how the latest Firefox 4 beta would compare for you.

therube wrote:But is it, necessarily? If you take into consideration a start from Session Restore, that act of restoring is kind of abnormal in itself. If you have LOTS of windows, LOTS of tabs (as I most often do), Session Restore opens/loads the whole shebang in a quasi-concurrent way.

This changed with Firefox 4.

>This changed with Firefox 4.

Right.