InformAction Forums

FF 3.6.3 NS 9.61
I had opened these sites in a tab thinking they are normal regular ones. But the downloads seem very fast (and they are not visible as anything worthwile) Also the processor usage goes up to nearly 100 % and comes down only on closing FF or ths site window.

http://www.google.co.in/url?q=http://ti ... SWc AD5TKA

http://timesofindia.indiatimes.com/ipla ... 797750.cms

Not seeing anything out of the ordinary - even Allowing Globally & disabling Adblock Plus?

Hi CPU usage generally points to Flash.
CPU usage subsiding when focus is changed to another page also generally points to Flash.

Actually with my Fx 3.6.3, the CPU usage and the memory consumption is exorbitant and ridiculously high. I have noticed lags and delays in EVERY site, including while posting here. Even using a clean profile with NO extensions installed, even NS, it goes to 68% CPU usage and drops to 16 and then goes back up, and it cycles every other second or so and it is consuming 152.7 MB in memory right off the bat. It is ridiculous. It IS Fx and since 3.x it has gone to hell and no better than another other piece of crap out there. They boasted how 3.x problems will be addressed in 3.6 which is supposed to be immensely fast *scoff* it is complete BS. It is progressively becoming more and more crap and each time they try a major release to "make it better" it fails worse and worse. I wish I had the time to video the whole session for you all to see that a profile with NOTHING and it still runs like there is a million tabs open and tons of flash running. I have even disabled EVERY plugin and it still occurs, so not a flash issue, its truly an Fx issue. Simple as that. I am ashamed that I ever promoted or put my faith in Fx thinking it would be better than IE. However, for all of IE's faults, its fast, efficient and works consistently and without issue, barring going to bad sites and getting screwed by malicious asses. By far the fastest browser I have ever used has been Opera, even better than IE and even in some cases faster than Chrome, but then again Chrome is a stripped down piece of half-ass-ware and by the time it gets its act together it will probably be no better than Fx is now. Here is a quick look:



What you are seeing is with a CLEAN profile, NO extensions, not even NS, typing this post and ONLY this tab open. Its using 16% CPU and spikes up to as high as 63% but I couldn't catch it during the screen shot but still 16% to post here is ridiculous and the 153 MB of memory to do so? Seriously?

The bug is here.
http://support.mozilla.com/en-US/forum/1/666023?

nagan wrote:The bug is here.
http://support.mozilla.com/en-US/forum/1/666023?

Thank you for letting us know. I have added my report to yours and added my information that might be different. Let's see how quick or never we get a reply

Using Process Explorer you can examine the firefox.exe process, including getting a graph of CPU & Mem usage (for a period of time at least).
http://technet.microsoft.com/en-us/sysi ... 96653.aspx

While I don't doubt what you're saying, there are untold variables that can play into what you're seeing.

There's that Google "bad site" database thingy that FF uses. It's a big file, it recreates itself every so often.
Ditto with the .sqlite files. They perform maintenance or whatnot. Different things happening in the background that can place a load.

Even NoScript caused issues in the past. This thread, perhaps starting around here, http://forums.informaction.com/viewtopi ... 6131#p6131 I started talking about CPU spikes ...

At the moment (SeaMonkey 2.1a) I have 19 windows & ~106 tabs open. And as I'm doing whatever, I'm using ~380 MB of ram with CPU spiking to ~20% - depending on usage.

Now believe me, I have seen much higher mem usage & CPU usage. CPU most often caused by Flash. There is not always a rhyme or reason. Like now, relatively low mem, & low CPU. For as long as my current session has been open & given the variety of sites I've visiting, I would have actually expected higher mem numbers. There have been times when actions seemed heavy, but not currently.

Generally I see higher numbers at home compared to what I see at my work. Tend to do different things at each location.

I'm sure there are plenty of high CPU / high mem usage FF threads & or a FAQ that's worth reviewing.


Oh, & closing FF (& now SeaMonkey 2.x) is very resource intensive (presumably) due to things like Session Restore & other housekeeping performed. (FF 2 & SeaMonkey 1.x closed & that was that.)

There have been NoScript issues where the script timeout window would pop-up.
Since NoScript is script-only this window should come up in most cases when NoScript is responsible for slow execution (I guess).

And concerning memory consumption:
Note that the Task Manager display is not reliable in certain situations. For example you can't compare the values given by the XP Task Manager with the ones displayed in newer Windows versions.
Maybe this tool might help in finding the culprit: http://technet.microsoft.com/en-us/sysi ... 35533.aspx (report where the largest block is)

@therube

I have no doubt other variables are present causing the slow down; however, when Fx chooses to use something that affects its performance, once again its a choice made by the developers that is putting a load on the system by THEIR application. Regardless of what variable Fx is accessing or what job its performing that is causing the slow down, it is done by FX and therefore an issue that Fx needs to resolve. Now if it was some third-party application that has nothing to do with Fx, then I agree with your assessment 100% and would be the first to apologize, but as long as it is the FX process that is slow, its indeed an application issue and therefore something that needs to be addressed. If trying to supe up their application by using technology that is slowing it down or is not performing as it should, then they should either try to optimize it and find a way to make it work better or not use that technology and go for something that has better benchmarks (all of which should have been noticed and done when they were alpha, beta, and RC testing the application). Ultimately this is a decision they made and if it affects their app for whatever reason, then it needs to be fixed, simple as that (they can't claim we have made it faster and better and yet not deliver that promise and say oh well it has to do tasks that slow it down). At least to me and I am sure all the others who are affected feel the same way or to some extent the same way (also it is not something that happens sometimes, it happens ALL THE TIME).

@dhouwn

I am aware of the differences in the task manager stats and I do my own benchmarks using professional tools and that's how I confirmed it, the task manager was the easiest to share since it is usually the best understood and has a smaller learning curve and most people can open up and go see it on their own machine rather than learn the tool that was used and have to go install it and possibly get frustrated when they can't figure it out. So simply put, it was the most commonly understood, recognized and used tool that I could show to make my point; otherwise, I have run benchmarks on it using various desktop configuration (hardware), various software configuration (OS), and various versions of Fx (final releases for each version) using a professional tool (industry standard for quality assurance and benchmarking - our business as consultants). Therefore, resulting in my statement and agreement on the fact that its running very slow. Now I considered NoScript and that's why I did ALL my tests without it/or any other extension or theme (except 3 parallel ones using NoScript added ONLY) to compare to the control item and it showed that NoScript (the version at the time was 1.9.8 or something, I have to check) was barely and by scientific standards (insignificant variance) addition to the overhead observed. This was also true when we compared the control items (1 from each major configuration hardware/os/version) with a copy of those profiles using 100 addons that are commonly used (determined based on popularity, AMO rating/recommendation, and those that have been known to be heavy on the overhead) and found that on average the added overhead to the base Fx performance (without ANY theme or extension) was capped at 10% at its highest point.

So again, the base application showed consistently that it DOES NOT perform as advertised and it DOES have a huge overhead and system consumption than it should. Also, we found that the differences in various hardware was minimal, but performance in different OS's were minimally significant (Linux - namely FreeBSD, Suse, Knoppix, and Unbuntu - performed the best comparatively - although there were significant differences between various packages of Linux as well but not enough to talk about - ie. debian based vs. not), and finally regardless of where it was run, the base overhead was deemed excessive based on comparison to any other browser (included were: IE [removed due to highest fringe performance], Opera [high performance], Safari [high performance but slightly lower than Opera], Chrome {and Comodo Dragon variation} [high performance that was better than Safari but fairly consistent with Opera] and Mozilla {Firefox & SeaMonkey} [lowest performance of all of them - with SeaMonkey performing at acceptable levels by comparison]. Once again I don't say what I say unless I have done my due diligence, I have been a hacker, programmer, and security/infrastructure engineer/consultant for 20+ years [I started hacking & programming when I was 14], so I don't say something unless I have done some legwork on it. Among the Fx versions - 2.x performed the highest, 3.x performed extremely poorly, and 3.5.x performed slightly better than 3.x but nowhere near 2.x levels and far below any other browser. So I don't know why but they shouldn't just dismiss it because its easier to do and just because SOME are not noticing the difference, those who use it professionally and/or heavily, DO notice it, and it should be addressed. One other element that was considered was how much memory leaks occur when the browsers were left running for various periods of time [benchmark variables were in minutes as broken down: 5, 15, 30, 45, 60, 90, 120, 240, and finally 12 hours and 24 hours to test the extreme fringe zones]. It showed that up to about 45 minutes the process/memory usage overhead was high but performance didn't suffer significantly until we reach about the 1 hour mark and after that point the processor/memory usage/AND performance declined at an alarmingly high rate while other browsers tested in parallel held their levels fairly consistent for up to 4 hours [lowest end by Chrome] and 14 hours [highest end by IE]. So as you can see, this is not some whimsical claim or half ass complaint, but rather an extensively tested and verified one. I have attempted to send the results to just about anyone I could find [by trolling the AMO, Mozilla, MozDev boards looking for those who are named as developers] but due to the open source nature and hodgepodge approach to development in Fx, there wasn't a SINGLE person who acknowledged it, or responded on it, or even took responsibility for being the person who would look into it. I love open source but in the case of Fx its being used as an excuse to justify poor quality and inconsistent and careless development. Simple.

@everyone

I am in the process of setting up an even more complex and detailed benchmark project using every browser, every variation and every major OS [we didn't do MAC because I don't have any in my own production or testing environment - but we are getting a G4 system donated for this purpose] to gather the data in a way that can be replicated, can be verified and cannot be disputed; so that we can publish it publicly, send it to every major IT literature/magazine, and the companies who make them, and I will post a copy here as well for all to see. The last one I did for my own benefit but this time it will be to prove a point and show it so clearly that it cannot be disputed or dismissed so easily anymore. Then we'll see if the court of public opinion has any power to get them to act or not. I am hoping to have it implemented by July since I am currently dealing with personal issues that I won't discuss here and have previous obligations that prevent me from doing anything of this magnitude any sooner, since I have major obligations and personal things coming up clear through end of June. So stay tuned I guess...

My Firefox memory usage is pretty good as long as I have no session restore tabs open. Have you changed the default cache settings? Because from what I read on the concerning Bugzilla entries, this is in most cases a bad idea (for now, before the great cache code overhaul, they are currently looking into using the Chromium caching code). Also, I considered Firefox 2 to be horrible concerning memory management (but this was also on computer a lot less RAM and was also using add-ons like TMP for some time).

BTW: I can't think of many reasons why RAM usage should increase when idling, there is certainly something wrong. I had such a problem with Google Chrome (dev) a while ago, where all processes together were taking up 3 GB of memory (!). Apropos Chrome, a nice thing about it is the built-in task manager.

dhouwn wrote:My Firefox memory usage is pretty good as long as I have no session restore tabs open. Have you changed the default cache settings? Because from what I read on the concerning Bugzilla entries, this is in most cases a bad idea (for now, before the great cache code overhaul, they are currently looking into using the Chromium caching code). Also, I considered Firefox 2 to be horrible concerning memory management (but this was also on computer a lot less RAM and was also using add-ons like TMP for some time).

I am not sure what you mean by the cache and if you can provide me a link to read up on, I would appreciate it; however, if you are saying what I think you are saying, we have tested with the default 50 MB cache size as well as 0 MB cache size and we found that the performance was not that much different with the 0 MB cache, although it did go slower and used up more memory; but not significantly much.

I run in private browsing mode, so I know it makes its own temporary disposable cache and since I dump everything each time I use the browser (I mean the WHOLE thing - cache, cookies, flash, etc) it should not be that much of a factor caused by the cache, unless its something else you are referring to. I would be thankful for the clarification and if you can point me to the discussion you mentioned, so I can take a look and account for it in my testing.

The problem is that often it revs up so much, that even with 4 GB of RAM on this machine and running a clean and tight OS, my entire screen becomes unresponsive and it will flash (Not responding) in the titlebar and then go away and then come back and then go away and I have watched the taskmanager (among other tools) and see that it happens because the CPU usage goes to 100% or very close to it and sorting by CPU shows Fx on the top consuming 80+% and each time it clears the (Not Responding) in the title, the CPU usage drops for the Fx process and then it spikes again and the screen freezes. This also affects any other tools like email or whatever you might have open too. When I use my system without Fx open, it runs like a charm and I never spike more than 60% usage, even with Acrobat Professional, PhotoShop CS3, DreamWeaver CS4, Outlook 2007, running simultaneously, I never exceed 50% but if I throw Spybot or Malwarebytes scanners in there, it will spike to about 60-75% but even then I never slow down or get screen freezing. However, I run JUST Fx and nothing else major open and it takes forever and spikes and acts like a fool. So you tell me...

BTW: I can't think of many reasons why RAM usage should increase when idling, there is certainly something wrong. I had such a problem with Google Chrome (dev) a while ago, where all processes together were taking up 3 GB of memory (!). Apropos Chrome, a nice thing about it is the built-in task manager.

Yes, I am aware of that, please refer to my comment in the first part. Usually spikes like this are poorly written loops, gratuitous access to the kernle, or even a memory leak which ultimately causes system instability. I am with you on that, I know that some things do that and that's all I want, is for them to acknowledge that a Fx profile with no extensions, running along (meaning no major programs open elsewhere) and sitting idle spikes like that, something is seriously screwy but they just dismiss it by blaming it on something else and wont' even bother looking into it.

Now, if I had the time and the awesome familiarity with Fx source code that Giorgio does, I would find the problem, fix it and suggest a patch but I don't have that kind of time or resource and so it becomes dependent on others to take up the bug report and that is not happening so far. If I had the patience and time to learn the stupid source code and how they write it, I would contribute but right now, its all I can do to just finish what's on my plate right now, adding that is not an option at the moment. Plus, to be honest, I am discouraged to even try to find the time because Fx has shown to be a fairly haphazard operation that, going like this, will ultimately not be worthwhile to waste time learning. Personally, if I was going to learn anything, I would focus on better browsers and invest in making their code better than to try and learn and work with Fx only to be fringed or ignored by the "lead" developers because they don't want to go that way and want to keep experimenting. And ultimately its all that time you invest and the browser goes under, you have wasted your involvement and contribution. Initially I tried to learn it and started working on getting my environment setup and read the API and try to learn it so I can take over some of the great extensions that died pretty much because there was no one to maintain them, so that I could work on those and maybe some day work on something new, but a few months into it, I started coming up against "super developers" "the bosses" "the gatekeepers" and their egos and realized, its like pissing in the wind, why bother. This is why I commend and applaud Giorgio for sticking with it and providing in my opinion the only truly great extension out there; although there are a few that I like and always wished would become one, that are not done by Giorgio, no offense intended to them - I recognize their efforts too, but usually they are not on top of it and bug fix like Giorgio, I don't think anyone does it as quickly and efficiently as Giorgio.

Don't know much about FF, but Chat is probably the best place to talk with #dev's.

And Bugzilla is the place for Bugs. Give them something quantifiable & they still may overlook it, but hopefully not .

Reducing memory usage - Firefox
http://kb.mozillazine.org/Memory_Leak

Session Restore
http://kb.mozillazine.org/Session_Restore

Ego's, yep I've heard a tiny bit of that.

In SeaMonkey (at least my take) is that there is basically one guy that runs the show. And if not for him there would be no show. There are others that help out, for sure, but the numbers are very small. If he decides he wants something & he does the coding, there isn't much anyone can do, because it is not like there is anyone else who puts forth the effort for an alternative. Session Restore happened (& it is a good thing) in SeaMonkey because one day some guy popped into Chat, got to talking, & said he'd like to port it over. If not for that guy taking the initiative, who knows when or if it would be there. In many (most) ways SeaMonkey is tied to do what FF does.

That said, each & every new SeaMonkey has been an (feature) improvement over the last, & has presented a better overall browsing experience. Have things changed? Yes. Have some not liked all the changes? Yes. Have some things regressed (like overhead from Session Restore & what not)? Yes. Nonetheless, I would take SeaMonkey 2.1a over SeaMonkey 2.0 over 1.1 over 1.0 over 0.x over Mozilla Suite over Netscape (of any incarnation) any day of the week.

Scribd to Ditch Flash in Favor of HTML5

After Apple and Microsoft have (finally!) publicly announced they are ready to pull the plug on Adobe Flash, the first makers of Flash webapps are starting to ditch it in favor of HTML5: As Techcrunch writes, Scribd, an online document hosting service, will focus its efforts on HTML5 from now on.

http://fredericiana.com/2010/05/07/scri ... -of-html5/

So you say you don't like Flash?
Give this HTML5 page a shot instead, http://www.scribd.com/documents/3096417 ... d-in-HTML5

You say you want to see spikes .

Well its been a long time coming and although it has potential to be exploited, namely using the web-fonts (which NS protects against BTW), it is a very good concept and I think it has much potential. Like any new technology it is subject to some tweaking and need for improvement I am sure when it is used widely in the wild but the foundation and the concept is quite solid. I mean how many can say they are not sick of plugins for this, plugins for that, I mean come on it gets ridiculous. Now, I didn't personally experience any performance issues by visiting the link you provided and in fact it loaded quite quickly (near instant) and performed very well and I spent time reading the WHOLE page just to make sure I gave it enough time. I will do more with it and see but it seems to perform reasonably well.

BTW, thank you for sharing therube, its always good to "see" you smile

Just attracting spam now. Locking.