6 ms·
Your comment is wrong on so many levels: • It's not even on topic. This post is not about general memory usage; it's about fragmentation in the javascript VM
by wheels 15y ago
Your comment is wrong on so many levels:
• It's not even on topic. This post is not about general memory usage; it's about fragmentation in the javascript VM – i.e. that a system object existing in a general memory page precludes that page from being garbage collected / deallocated even though the lifetime of system objects is very different. This is not a trivial matter for which the only explanation is laziness.
• It's spoken like someone who's never seriously worked on a large open source project. Memory profiling and leak tracking is done widely and often (using valgrind, mostly).
• You speak as if you know how much memory a web browser should use. How do you know? Have you worked on modern web browsers? Or are you just, as I assume, by fiat deciding that 500 MB is too much?
• There's very often a speed / memory usage tradeoff. At present, especially for web browsers, users tend to prefer speed. (i.e. how many rendered pages do you cache per tab so that clicking the back button is next to instant?)
• The right time to profile and optimize is usually later in the development process. We all know the famous quote. Optimizing early tends to lead to ugly code that, amusingly, is harder to optimize later.
- z92 15y agoI remember sometime back probably around 2004. There was a lot of noise regarding memory leak in FF. And the expert sounding ones started to claim that there was no memory leak and the very large memory usage in FF was because of browser history and cache storage. Then one year later they all accepted that FF was actually leaking memory. Since then I stopped accepting expert opinion blindly.
- wheels 15y agoExperts are sometimes wrong. That doesn't change the fact that they're right vastly more often than non-experts.
- clobber 15y agoI could be wrong, but wasn't a large part of this due to Flash?
- starwed 15y agoI think it turned out that a large part of it was due to, like, 100 different small things. There was never a memory leak.
- bzbarsky 15y agoThere is an important difference between "expert-sounding" and "expert". Where memory leaks (or pretty much any performance metric) are involved, the more sure someone sounds, the less likely they are to be an expert unless they have done extensive measurements to back up their claims.
- jbert 15y ago> • There's very often a speed / memory usage tradeoff. At present, especially for web browsers, users tend to prefer speed. (i.e. how many rendered pages do you cache per tab so that clicking the back button is next to instant?) This is a good point, and the amount of memory used for such a cache is ideally "all of it, but no more". Which is the same argument for buffer cache. So I wonder if it's possible to use the buffer cache in this way? Perhaps write the rendered image to a tmpfile. Then don't sync the write and also something like fadvise(FADV_DONTNEED). The app can then free the memory. (Clearly you could play a similar game with mmap()). The idea would be to have the memory sitting in the system buffers. But the app can inform the system that these pages are discardable under memory pressure, rather than needing to be written to disk.
- bzbarsky 15y agoWhat's being cached in the "rendered page" case is not an image but an object graph in memory. Writing that to disk involves either fixing up all the pointers on read or making sure you can read it all back into _exactly_ the same locations in your virtual address space or something. This can still improve performance over creating the object graph from scratch (c.f. XDR for Gecko's JavaScript or Mozilla's fastload stuff for the user interface), but not nearly as much as just having the object graph there. One other note: just because _you_ don't sync the write doesn't mean some other random part of your app, or some other app, won't.... and then you have extra disk traffic.
- jbert 15y agoWell, you either serialise/deserialise your data structure to make it memory relative, or you could use mmap(). Allocate such pages with a malloc which works out of an anonymous mmap() backed pool, with madvise(MADV_DONTNEED). The OS will then discard the pages under memory pressure and will give you back zero filled pages if they have been discarded. If each object has a nonzero sentinel value and is smaller than a page, you can detect discarded objects. Objects bigger than a page can be composed of a 'dictionary obj' which pts to multiple objects - check the sentinel on each and discard/rebuild the whole lot if any are missing. That last bit may be hard to retrofit, I agree.
- srean 15y agoWhile not right square on topic I dont think the parent post was so off target compared to digressions and explorations that are common on discussions here that it warranted an admonishment. I have not "worked on modern browsers" and that seems to disqualify me from expressing an opinion on what I consider using too much as an user of a piece of software. But this much I can say, that even a few years back I could comfortably use a Linux desktop on 64MB RAM. Now even a Debian box with X would run rather choppily on a system that has 256MB and it is not very clear to me in what exact way is my compute experience better now than the one that I had on the 64MB system. Even those that are considered a lean browser, take upto 200MB of that 256 and still does not work smoothly.(FF 3.5 still does fine on this system BTW). Had my old system been augmented with some 3Gigs of RAM it is possible that its performance would be worse than a modern system of equivalent RAM, but now that it is common for a system to occupy more resources to accomplish the same level of activity is at times an irritant. The usual counterargument is that RAM is cheap and one should just go and buy some or suffer otherwise. I think it is this assumption that is made or a requirement that is imposed by the newer versions of software that GP was complaining about.
- hapless 15y ago"Comfortably use" my eye. Web browsers have always been bulky by the standards of their day. I remember using IRIX on a 64MB SGI Indy and cursing. It thrashed swap furiously with Netscape 4. Today's agony always seems new and fresh, but it never is. I still have some of those old systems sitting around to remind me. The "good old days" were pretty miserable. Today I have Linux and Firefox and the exact same problems -- in 1G of RAM, which is a comparably low-spec system today to what the Indy was back then. The more things change, the more they stay the same.
- deleted 15y ago[deleted]
- mike-cardwell 15y ago"There's very often a speed / memory usage tradeoff." And yet Firefox seems to use about 4 or 5 times more memory than Chrome on my system whilst being noticably slower as well... If Chrome had all the addons that Firefox had, Firefox would be a dead browser. I still use Firefox as my primary browser. For now.
- itsnotvalid 15y agoI have the inverse of your situation that chrome always use much more memory than firefox.
- william42 15y agoThat's because 1) Chrome is better-designed 2) Chrome extensions are JS and not native code, meaning they're less likely to leak due to programmer error, and there are fewer of them, to boot
- lmz 15y ago> 2) Chrome extensions are JS and not native code, meaning they're less likely to leak due to programmer error, and there are fewer of them, to boot Are there really that many Firefox extensions that use native code?
- udoprog 15y agoSide note: Firefox extensions aren't native code, they're written in JS. EDIT: I do however agree that chrome is more well designed. Firefox has been through a lot of iterations through the years.