InformAction Forums

Giorigio,

I accidentally noticed that when toggling temp allow for a page (no reloading), the cpu briefly spiked to 40%-50%.

Thinking that this is abnormal, I investigated a bit and found the cause. When you toggle temp allow, NS casues Fx to write the entire prefs.js to disk. When prefs.js is relatively large (~ 100K) Fx2 spikes to ~ 50%.

I don't have any issues with high cpu utilization on disk access, so I think this is a Fx inefficiency when saving prefs . And sure enough, in Fx 3.5.5 the cpu spikes with the same 100K prefs.js don't go above 15%, which is still probably too high.

If NS used its own pref store (which has other benefits also) and on top of that did not save temp allows to disk, I don't think there would be any spikes at all. But even with the current system, maybe you can avoid saving all the prefs for temps?

al_9x wrote:If NS used its own pref store (which has other benefits also)

I'm afraid that's impossible: NoScript's script blocking is based on CAPS, which is the only reliable way to disable scripts per-site.

Giorgio Maone wrote:

al_9x wrote:If NS used its own pref store (which has other benefits also)

I'm afraid that's impossible: NoScript's script blocking is based on CAPS, which is the only reliable way to disable scripts per-site.

Just want to make sure I understood. You're referring to the "capability.policy.maonoscript.sites" pref, which you have to modify for temp allow, is that right? And updating it forces Fx to write prefs.js? So the bottom line, there is no way to avoid these spikes?

al_9x wrote:

Giorgio Maone wrote:

al_9x wrote:If NS used its own pref store (which has other benefits also)

I'm afraid that's impossible: NoScript's script blocking is based on CAPS, which is the only reliable way to disable scripts per-site.

Just want to make sure I understood. You're referring to the "capability.policy.maonoscript.sites" pref, which you have to modify for temp allow, is that right? And updating it forces Fx to write prefs.js? So the bottom line, there is no way to avoid these spikes?

Yes you understood correctly. However, now that I think about it, I probably can try to make Firefox delay the file flush until it's absolutely necessary (you'll get the spike, but later, whenever you save any other preference).

When you toggle temp allow, NS casues Fx to write the entire prefs.js to disk.

How did you determine that? Process Monitor or similar? (And if so, how did you set up your filters?)

When prefs.js is relatively large (~ 100K) Fx2 spikes to ~ 50%.

Heh. Mine is only 15 KB yet there is still that hit.

And I've had a sneaking suspicion that I see something similar with Adblock Plus, Right-Click Context Menu Slow & Heavy.

Giorgio Maone wrote:I probably can try to make Firefox delay the file flush until it's absolutely necessary (you'll get the spike, but later, whenever you save any other preference).

I see plenty of CPU spikes just from normal Firefox use. Is this particular one a problem? I get a little nervous when you start considering messing with Firefox IO for something that's not problematic. It also adds unnecessary complexity to NoScript.

therube wrote:How did you determine that? Process Monitor or similar? (And if so, how did you set up your filters?)

Process Monitor verifies that prefs.js is written for both Temp Allow and middle-clicking the Adblock Plus status bar icon. Process Explorer shows that the total CPU hit is 1 CPU second for NoScript TA (not counting the page reload, which uses much more CPU than the prefs.js activity.) I still don't see that it's problematic.

Dual 600MHz PIII CPUs
Process Monitor filters:
Include Process Name firefox.exe
Include Path path to prefs.js file

Well it is resource intensive, for a relatively long duration.
(Relative as in long compared to other system expenditures, but short compared to a hung process hogging 50% CPU.)

And while in the scheme of things it may not be that big of a deal, but considering every action taken puts some sort of hit on your system (something as simple as pressing a key on the keyboard), it all adds up. So anything that can be done to lessen the hit will improve performance.

Throwing a bigger CPU into the mix is not an answer.
Take XP. Runs fine on all types of systems. Upgrade to Vista, & if your system was marginal before, it now runs worse. More "junk" added in, so what worked, before is now a pain to use. Throw in a bigger CPU & you're happy again. (But then look at it as if you threw that big CPU into XP. Then instead of "happy", you're wow!) Same thing with A/V. You have a well running system, throw in an A/V & it drags your performance down. Now you've got a big CPU, so you don't notice it. But remove your A/V & you've got wow again. Put that same A/V on your already marginal system & now you've got a dog.

therube wrote:Well it is resource intensive, for a relatively long duration.
(Relative as in long compared to other system expenditures, but short compared to a hung process hogging 50% CPU.)

Short compared to the page reload caused by the Temp Allow change.

I'm not suggesting the solution is a bigger CPU. Mine is over nine years old and pretty low-end now, but this prefs.js write does not appear to be problematic in any practical sense even on my old, slow system. You don't effectively streamline software by "fixing" everything you can. It's better done through optimizing the bits that give you a worthwhile trade-off between performance and software complexity and maintenance. Of course that's the decision Giorgio will make.

Giorgio Maone wrote:However, now that I think about it, I probably can try to make Firefox delay the file flush until it's absolutely necessary (you'll get the spike, but later, whenever you save any other preference).

1) Though you're not calling flushCAPS on temp allow in .23 , it is still saving prefs and spiking
2) This bug appears to be caused by these flush changes. You get the flash placeholder after allowing colbertnation.com but not after temp allowing

Please check latest development build 1.9.9.24

Giorgio Maone wrote:Please check latest development build 1.9.9.24

1) .24 no longer flushing prefs on temp allow but does on forbid, curious, why is on forbid needed?
2) unfortunately the cpu spikes are still the same on temp allow despite the lack of disk io. It makes sense that it was never the actual writing of a 100k, but something concomitant to it, that Fx is still doing.

PS: Not sure I'm noticing any difference with this, x Reduced disk activity on permission change (thanks al9_x for RFE)

Ditto in .24.

al_9x wrote: 1) .24 no longer flushing prefs on temp allow but does on forbid, curious, why is on forbid needed?

Because if preferences hit the disk for any other reason after you granted temporary permissions, NoScript need to overwrite them in order to remember only the current permissions set (without the sites you just forbidden).

al_9x wrote:It makes sense that it was never the actual writing of a 100k, but something concomitant to it, that Fx is still doing.

Probably CAPS parsing the sites and building its hash tables for fast permission checks. It's always a read/write performance tradeoff, and in this case having fast reads is obviously preferred.