Slashdot Mirror

http://it.slashdot.org/comments.pl?sid=2061048&cid=35681060

(Hairyfeet's SUCH a dumbass, he doesn't know the diff. between STATICALLY ADDRESS IP BASED banners & DYNAMICALLY ADDRESSED ONES using host/domain names!)

LOL, I mean, ok - listen to his b.s. ALL YOU WANT, but only AFTER you read the URL from this website above, lol!

(He sure is a "big talker" though, isn't he? Ripping others' work but he can't show he's done better... & he CERTAINLY SHOWED he is a fuckup in his "tech know-how" above!)

Another instance of his "big talking b.s." is here:

http://slashdot.org/comments.pl?sid=2029850&cid=35450222

He says "automating McDonalds would be 'easy'" but he's NEVER DONE THAT... I have (one of the programmers for them, Boston Market, & Burger King's "bump bar" system).

Oh, incidentally, on FF "leaking memory"? It used to have a problem with MEMORY FRAGMENTATION:

http://blog.pavlov.net/2007/11/10/memory-fragmentation/

(NOW - THAT? That should be fixed now, but it's still a possible... only speculation here though (& I am one of the folks that have helped FF's teams FIX BUGS before in the past, @ NTCompatible.com)).

I am the guy that designed the VERY first FIRST GUI Windows Memory Defragmenting program ( that many others copied after)...

Microsoft designed the FIRST though, in clearmem.exe (albeit console mode app only, & NOT schedulable - block freeing RAM defragments it by forcing to pagefile.sys, & page coloring does the rest on re-access).

Fact is - My program, and yes, MS' are good enough to stop Exchange Servers halting in fact, worldwide, until it went 64-bit, & my program's commercial ware.

APK

P.S.=> Just "too, Too, TOO EASY - just '2EZ'", but then again? "Pwuffesuh HaiwyPheet" is only an "ITT Tech Boy" techie... lol! apk

Memory fragmentation will cause a program to use more memory, not cause it to slow down. Since Firefox moved to jealloc in 2008, memory fragmentation in Firefox is low. As with memory leaks, these problems were fixed years ago, but users still complain that the problems are being ignored and not fixed.

Memory fragmentation will cause a program to use more memory, not cause it to slow down. Since Firefox moved to jealloc in 2008, memory fragmentation in Firefox is low. As with memory leaks, these problems were fixed years ago, but users still complain that the problems are being ignored and not fixed.

Sorry, it's clear you're making it all up. Many tests show Firefox uses less memory than other browsers, and Firefox's usage has never significantly declined. Your post is purely fabrications.

Ok, have fun in fairy tale land... I'll stick with Chrome.

Sorry, it's clear you're making it all up. Many tests show Firefox uses less memory than other browsers, and Firefox's usage has never significantly declined. Your post is purely fabrications.

Quite a bit of work on memory usage and fragmentation was done for Firefox 3. See this blog. Personally I have no problem with stability or memory usage.

I am not sure what would qualify a benchmark as "real world" but this (some comments here) looks pretty realistic, and might be enough to give you your shock:

You totally misread that article. There's no NDK. That's not the same thing as preventing people from creating applications themselves. If they can figure out how to do it, and it passes inspection, Microsoft may carry it. Until they make a statement or perform an action indicating otherwise, you're just spreading FUD, which we call Trolling.

This is directly from the guy in charge of FireFox for mobile devices.....

http://blog.pavlov.net/2010/03/22/stopping-development-for-windows-mobile/

While we think Windows Phone 7 looks interesting and has the potential to do well in the market, Microsoft has unfortunately decided to close off development to native applications. Because of this, we won't be able to provide Firefox for Windows Phone 7 at this time. Given that Microsoft is staking their future in mobile on Windows Mobile 7 (not 6.5) and because we don't know if or when Microsoft will release a native development kit, we are putting our Windows Mobile development on hold.

How much clearer can it be?

If Apple really cared about empowering the user in the style, manner, and spirit of their legendary 1984 commercial, they would make Flash available -- or rather allow Adobe to make it available -- on the iPhone, Touch, and iPad, and allow the user to decide which user experiences work best for them. Apple only cares about profits and control these days, having become the very thing they once railed against.

Does that apply to the Mozilla Foundation too?

Firefox for Maemo RC3
We’ve decided to disable plugin (not to be confused with add-ons, which are supported) support for this release. The Adobe Flash plugin used on many sites degraded the performance of the browser to the point where it didn’t meet our standards.

Attempting Flash playback on a phone cripples the device because there is no hardware support for vector graphics.

Design is not just what it looks like and feels like. Design is how it works. --Steve Jobs

Flash Lite doesn't. Hell, even my badass Mac Pro freaks out playing Flash. I just tried and got WebKitPluginHost at 93% on one core. Look, Flash performance on OS X *desktop* is abysmal, it is utter crap. You don't want that on your iPhone.

You can't just ask customers what they want and then try to give that to them. By the time you get it built, they'll want something new. --Steve Jobs

Latest version of 3.5, and I listed my extensions in another post.

Thanks for the link though - I remember applying a few of those when I first started running into problems a few years back (2.x was abominable for memory usage), but I found they were only marginally effective - they key issue is page fragmentation, so even if you place hard limits on the amount of memory to be used as cache you still end up with that memory being "exhausted", eventually leaving little to no space for cache... and you're back to crappy performance again.

Don't know if you ever saw Pavlov's blog about the fragmentation issue, but it makes an excellent read: http://blog.pavlov.net/2007/11/10/memory-fragmentation/

As mentioned on the nedmalloc page, glibc uses ptmalloc which (on average) isn't that slow.

glibc 2.3's malloc certainly isn't optimal for every possible workload but it doesn't tend to be incredibly poor for any workload either. For Firefox on Linux switching to jemalloc didn't cause as big an improvement as it did on Windows.

And the memory leaks are ridiculous, even as system with lots of Ram will be brought to its knees by FF given enough time.

Except IE7 does "leak" memory like sieve, (it's hard to tell exactly what it's doing) at least in comparison to Firefox.

Consider the following link. It is by a well-known Mozilla developer, so while he may be biased you can be sure that a result that cannot be reproduced would set the tubes on fire some time ago.

http://blog.pavlov.net/2008/03/11/firefox-3-memory-usage/

I'm not saying that Firefox is the leanest application ever, but some of the charges against it here are incredibly overblown and of dubious veracity.

Nice to repeat the same ol' FUD, but you do realize that FF3 memory usage is significantly lower than FF2 and IE, don't you? You /did/ know that, right?

Memory on the OSX Firefox is tougher to release because OS X doesn't do anything with the madvise/msync syscalls used on free up memory on some other platforms (see Measuring Memory Use). OSX memory usage should apparently level off at a peak though.

In fact, I think this was not really an experiment at all; there was no formality in setting and regulating variables and controls. This was "real-world", using the author's actual pattern of browsing - an anecdote with pretty graphs. It has some value, but the article makes itself sound more scientific than it deserves.

That said, there's still other evidence that Firefox 3 uses the least memory out of these browsers (i.e. the tests where "people load hundreds of web pages, sometimes at the same time" as mentioned in TFA). For example, here's one with Fx2, Fx3, and IE7.

Look at this article talking about memory usage in Firefox 3 by mozilla dev Parlov. There is a graph there that suggests Firefox 2 uses around 80Mbytes more memory than Firefox 3 over time.

If you check this fairly lengthy explanation of how memory usage was improved in FF3 you'll see that it is mostly attributed to reduced fragmentation and leaks, and smarting caching, just as you are advocating.

db

Actually, most extensions have been updated for FF3, and one of the changes made in the allocator allows for automatic cycle collection. Previously, extensions had to break cycles themselves, making it relatively easy for them to leak memory, but with automatic cycle collection, it's easier to write a leak free extension. See this article on memory improvements

• Reduced Memory fragmentation
• Fixed cycles with the Cycle collector
• Tuned the caches
• Adjusted how image data is stored (hint: compressed)
• Hunted down leaks. "Overall, we've been able to close over 400 leak bugs so far, most of which are very uncommon, but can still occur."

• VMs have comically bloated memory footprints: between 2x and 30x comparable C programs according to benchmarks: JVM, Mono. Even if you consider memory cheap, smaller is always better because it means fewer bits flying over the bus and better cache utilization.
• VMs stop the world to do garbage collection. Point me to all the articles you want that explain how "it's getting better" and "they've figured out how to make it real-time," but that doesn't change the fact that you're stopping all threads whenever you garbage collect, which is making your latency suffer.

C and C++ are the only game in town for getting the best performance and a small memory footprint and the ability to have the lowest possible latency.

That said, I think that C and C++ are becoming harder to justify when you consider the havoc that memory errors can wreak. It's highly embarrassing to vendors and damaging to their customers when a buffer overflow exploit is discovered. malloc and free, even when used correctly, can still have some forgotten downsides like the memory fragmentation that was discovered in Firefox 2, and took some very smart people a lot of work to address.

What I would like to see is a language that gives the benefits of C and C++ (extremely fast, extremely small memory footprint, and no GC pauses) but that is also immune to C and C++'s weaknesses (memory corruption, memory leaks, memory fragmentation). Yep, I pretty much want to have my cake and eat it too. Why do I think this is possible? I think that the future is to have a fully concurrent, compacting GC. Everyone's telling us we're going to have more cores than we know what to do with soon, right? Well why not use all those extra cores to do GC in the background? Even if it's more expensive on the whole, we barely know what to do with all those extra cores as it is. With this strategy, you could get the performance guarantees and low overhead of C and C++ (on the real, non-GC thread, that is) without having to give up GC or suffer from memory fragmentation.

I'm also not willing to give up the option of dropping to C or C++ (or even assembly language) when it's justified. Mention JNI in a room of Java people and observe them reel in horror -- it's culturally shunned to deviate from "100% pure Java." Maybe this is a good value when you're on a big team of people writing a web app, but for systems and multimedia programming this is silly -- inner loops are inner loops, and some of them can benefit from machine-specific optimization.

Theoretically you could experiment with the fully concurrent GC using an existing language/runtime like Java, but I've sort of given up on the JVM and .NET communities, because they have empirically demonstrated that they culturally have no regard for small memory footprint, low overhead, short startup time, etc. They just don't consider huge memory footprint or ridiculous startup times a problem. This is not to ment

http://blog.pavlov.net/2008/03/11/firefox-3-memory-usage/
http://blog.pavlov.net/2007/11/15/less-fragmentation-coming-in-firefox-3/
http://blog.pavlov.net/2007/11/14/leaks-memory-we-never-forgot-about-you/


Cheers.

http://blog.pavlov.net/2008/03/11/firefox-3-memory-usage/
http://blog.pavlov.net/2007/11/15/less-fragmentation-coming-in-firefox-3/
http://blog.pavlov.net/2007/11/14/leaks-memory-we-never-forgot-about-you/


Cheers.

http://blog.pavlov.net/2008/03/11/firefox-3-memory-usage/
http://blog.pavlov.net/2007/11/15/less-fragmentation-coming-in-firefox-3/
http://blog.pavlov.net/2007/11/14/leaks-memory-we-never-forgot-about-you/


Cheers.

Nothing strange about it. He is most definitely using Firefox 2, and due to its caching system and a lot of badly written plugins it leaks memory, a lot of it. I don't really want to repeat myself, but the platform on which Firefox 3 is built on has been significantly changed and therefore it has a smaller memory footprint.

Doesn't Firefox already use up enough memory? Currently Firefox is running on my computer using up nearly 800MB of RAM. I have 3 tabs open and none of them are doing anything intense. I'm glad my computer has 2 gigs of RAM but I bought that for Photoshop not Firefox...

Mozilla developers have made a lot of significant changes to the platform on which Firefox 3 is built on, many of those aiming to reduce the browser's memory footprint.

You should read the post (http://blog.pavlov.net/2008/03/11/firefox-3-memory-usage) linked from the ars article. It explains the graph, this article just simply puts it there.

The drop off in the end is the behavior after you close all the tabs and wait some time.

Out of curiosity, what's the dropoff and flatline near the end of both Firefox lines on the graph? Anyone know?

From the original blog post:

For the results below we loaded 29 different web pages through 30 windows over 11 cycles (319 total page loads), always opening a new window for each page load (closing the oldest window alive once we hit 30 windows). At the end we close all the windows but one and let the browser sit for a few minutes so see if they will reclaim memory, clear short-term caches, etc.

So that is all the memory being reclaimed upon closing all but one of the windows, and then doing nothing whatsoever.

Yes, they did fix it!!

There is this post over the fixes - http://blog.pavlov.net/2008/03/11/firefox-3-memory-usage/ As you go through the link, you will realize FF has made a serious effort in fixing it.

And, if you, just like me, give it FF3 a shot - you will be delighted with the speed. It's awesome!

I thought it was me providing you information to help you figure out your problem. If it's occurring only on your machine, that sounds like it's the number (2) situation I describe. If you still think it's the number (1) situation, it's still up to you to write a useful bug report. You can read what folks are saying about Firefox 3, and I don't see any hint of it having any memory problem. In fact, they seem to be saying there isn't one.

We're not being fanboys. We're giving you the facts of the matter. If you still don't believe us, read what a Firefox developer has to say about Firefox memory usage. There is no one major memory leak. There are lots of things that can possibly cause Firefox to use lots of memory over long periods of time: caching, fragmentation, small memory leaks adding up, etc. It looks like Firefox 3 uses less memory than Firefox 2, and both use less memory than IE (see the second graph in the page I linked to).

http://blog.pavlov.net/2007/11/10/memory-fragmentation/ provides information about this issue. Supposedly a lot of the memory eating issues people bitch about are caused by heap fragmentation -- memory pages that get allocated to Firefox, then some of the data freed, but not all of the page.

You haven't even mentioned the number one problem that makes Firefox slow when it's been open for too long: memory allocation costs associated with heap fragmentation.

Here's a blog post that gets as close to an official description as I can find. It was linked from the Mozilla developer newsletter.

To the best of my knowledge, Firefox typically does not leak memory, at least in the conventional sense that references to memory are erroneously discarded and unused allocated memory cannot be freed. Instead, the actual heart of the issue is supposedly memory fragmentation:

http://blog.pavlov.net/2007/11/10/memory-fragmentation/

As the linked article suggests, memory fragmentation can be reduced by replacing heap allocations with stack variables, where possible, in hotspots such as the JavaScript engine. As for the heap allocations that cannot be dealt away with in this manner, effort can be made to group them together such that they are less likely to cause fragmentation.

There was a post over on reddit a few weeks ago regarding this topic spurred by this blog entry

Memory use is a combination of necessary memory use, caches, memory fragmentation, and memory leaks. What you're describing sounds like memory leaks, not caching. The good news is that in Firefox 3, Mozilla developers' "extensive testing shows an occasional leak here and there and we are working to fix those, but in general we aren't seeing many leaks anymore." If you see any way to reproduce any memory problem in Firefox 3, please report it with the set of steps used to cause the problem.

They've already said "Our extensive testing shows an occasional leak here and there and we are working to fix those, but in general we aren't seeing many leaks anymore." It seems like they've done everything you've suggested (except for the bounty), and yet you still seem unsatisfied. Isn't that proving our point?

I'm the lead for a group of over 20 engineers and programmers that produces public safety communications equipment and have direct experience with memory leaks large scale C++ projects AND Firefox. The system we sell includes embedded devices, a Linux/Oracle/Apache server for management, and management terminals. Management and monitoring is done via web browser, either on Windows or Linux. We officially support both Firefox and IE, and both leak memory. We strictly control what is installed on the management PCs - no browsers extensions, no ActiveX components, no Firefox Ad-ons. Typical usage is to open the browser and monitor one page continuously for weeks until an alarm is shown.

Let me be clear, both Firefox and IE leak memory so badly that even on management PC with 2GB of RAM we have to require the end user to restart the browser every week. We are monitoring FF3 and looking forward to reduced memory leakage. In the referenced article it discusses reducing memory fragmentation. OK, that's a worthy goal but first fix the memory leaks. Memory fragmentation and memory leaks are related, but different beasties. A memory leak almost always results in fragmentation, but fragmentation can happen simply from an unfortunate memory allocation/deallocation pattern.

Regarding C++ and memory leaks: over 2 1/2 years we've worked on the embedded code, which is pure C++, we have hunted exactly one memory leak. And that leak turned out to be from the OS. We use Boost smart pointers, RAII, exceptions, and exception safe code. We have no trouble with leaks or fragmentation, despite a fairly high turnover rate and a customer base that would quickly notice memory leaks requiring reboot of the embedded devices.

Form the tests that the developers have been running, most of the memory leaks in Firefox itself seem to be fixed (there are probably still some left). However, memory usage still remains a problem. I think this blog post summarizes their findings. They've been using dtrace and other tools to find out exactly what is going on.

Unfortunately, I think the damage to Firefox's reputation is already done. There are many people who have had negative experiences with Firefox who keep on harping about the "memory leaks" and I don't see how Mozilla devs can change this public perception.

http://blog.pavlov.net/2007/11/10/memory-fragmentation/

An interesting read on how memory fragmentation adversely affects FireFox... & why/how.

APK

P.S.=> I also recommend Opera for these reasons (less security holes period, & the 1 it had yesterday? Patched yesterday too... fast!)

SECUNIA DATA ON BROWSER SECURITY (dated 11/20/2007):

Opera 9.24 security advisories @ SECUNIA (0% unpatched):

http://secunia.com/product/10615/?task=advisories

----

Netscape 9.0.0.3 (0% unpatched)

http://secunia.com/product/14690/

----

FireFox 2.0.0.9 security advisories @ SECUNIA (29% unpatched):

http://secunia.com/product/12434/

----

IE 7 (latest cumulative update from MS) security advisories @ SECUNIA (37% unpatched):

http://secunia.com/product/12366/

----

Those %'s are the latest for FireFox 2.0.0.9, Netscape 9.0.0.3, IE7 after last "patch Tuesday" from MS with the "CUMULATIVE IE UPDATES" they have (see the security downloads URL I post in the 12 steps above to secure yourself), & Opera 9.24... all latest/greatest models.

So, as you can see?

Well, NOT ONLY IS OPERA MORE SECURE/BEARING LESS SECURITY VULNERABILITIES?

It's faster too, on just about ANYTHING a browser does, & is probably the MOST standards compliant browser under the sun (not counting HTML dev tools). This is borne out in these tests:

http://www.howtocreate.co.uk/browserSpeed.html

AND, yes others (most recently in Javascript parsing speeds, oddly enough, lol... given the topic of my post here that is), right here:

http://nontroppo.org/timer/kestrel_tests/

Opera's just more std.'s compliant, faster, & more secure than the others... so, "where do you want to go today?"...

apk

I cannot see memory footprint "rise and rise" no matter what I do. Firefox developers have been working on memory leak bugs for years. They have fixed about 100 in the past year alone. Memory leak bug reports are not at the bottom of the priority list. In fact, they've fixed so many memory leaks that "Our extensive testing shows an occasional leak here and there and we are working to fix those, but in general we aren't seeing many leaks anymore."

Our heap is now 29,999,872 bytes! 16,118,072 of that is used (up 4,634,208 bytes from before... which caches am I forgetting to clear?). The rest, a whopping 13,881,800 bytes, is in free blocks! These are mostly scattered in between tiny used blocks. This is bad.

The actual amount of memory used is very low. The problem is fragmentation. If Mozilla would actually tackle the real problem instead of focusing on what know-nothing users continuously claim is the problem, it would probably be fixed already.

This problem could be easily solved with a moving garbage collector, but there are far too many developers in this world thinking "GC iz 4 teh n00bz im a r33l h4rdk0r pr0gr4amar I dont n33d th4t babi stuf".

See pavlov.net blog on Memory fragmentation in firefox.

I ran in to this problem back in the days where 4MB of memory was a lot. My program needed a lot of large objects with a short persistence. The upshot of this was that the program soon ground to a halt due to swapping memory I partially overcame the problem by writing my own allocation algorithm which kept separate lists of blocks of different sizes, hence it managed to recycle much of the memory blocks.

Yes, it still has memory leaks. I'm sure all popular browsers have memory leaks. Memory leaks are like crash bugs. You can make crashes less and less common, but it would take nearly a miracle to produce a browser that never, ever crashes no matter what. Similarly, Mozilla developers have worked for years to reduce the leaking of memory, but you can't expect a release with absolutely no memory leaks whatsoever. Mozilla developers report "Our extensive testing shows an occasional leak here and there and we are working to fix those, but in general we aren't seeing many leaks anymore."

I"m sure that many of the memory leaks have been fixed. However, they may not be the biggest problem. One of the developers has been making some really interesting posts about Firefox's memory fragmentation problems. http://blog.pavlov.net/
Those have yet to be solved.

Actually, many Firefox devs now use Macs as their primary desktops.

That's the problem. FF2 is based on Gecko 1.8.1, which is now over 2 years old. FF3 (the first beta should be out in a few weeks) will be based on Gecko 1.9, which will have a mind-bogglingly large number of refactorings and core fixes (literally, several thousand bug fixes/enhancements and several millions of lines of code changed). The Mac graphics code now uses Cocoa widgets on top of Quartz (through Cairo) as opposed to Carbon widgets on top of Quickdraw; there's a new Mac theme, and HTML forms are now rendered as native widgets. The result is that FF3 now looks and feels like a native Mac app. Oh, and Linux support will see many improvements in FF3; see this blog post for details, and this one for information on what needs to happen next.

As for memory use, Gecko 1.9 has seen a lot of memory-related work, including a cycle collector for XPCOM (their COM system). Memory leaks seem to be way down. One dev thinks some memory problems might not be due to leaks but rather memory fragmentation. Planned for the big Mozilla 2 rewrite (to be in FF4 or later) is the whole new Tamarin VM (based on that big contribution from Adobe), which will perform garbage collection on the entire codebase.

For now, though: Often memory leaks are caused not by FF itself but by extensions; try running through a typical browsing session in Safe Mode and see how the memory usage compares.

After opening the browser and going around Google maps for several minutes, I got memory use up to 55 MB. After opening 20 Yahoo articles in 20 tabs, memory use went up to 94 MB. After closing all tabs but this one, memory use went down to 66 MB. After going to Slashdot and opening the pages for comments for all articles in current stories, memory usage went up to 148 MB. After closing all tabs but this one, memory use went down to 89 MB. After opening about 30 articles from the NY Times in different tabs, memory use went up to 118 MB. After closing all tabs but this one, memory use went back down to 85 MB. I'm using the latest nightly build of Firefox 3 on Windows.

Sorry, I don't think the problem is my attitude. I simply cannot reproduce the problem of Firefox using hundreds of megabytes for no reason, no matter how hard I try. All I see is memory use hanging around 100 MB, just like I see in all browsers. That's due to memory fragmentation and caching, which I see in all browsers. Believe me, if I could see a problem, I'd be right there reporting it. Why would I not want a serious problem fixed? If you think the problem is my attitude, feel free to discuss the problem on the Firefox Bugs forum at MozillaZine. Certainly there can't be such a widespread conspiracy that we're all going to deny a serious, obvious problem?

Actually the high usage of memory is usually not caused by memory leaks. Read Stuart Parmenter's blog for more info regarding Firefox memory allocation and fragmentation. He has done some interesting research.