|
Lum posted:Indeed it can, so now running 64bit Pale Moon 6. More than 3GB, actually; they made it LARGEADDRESSAWARE with 4. Ryokurin posted:A lot of what they were doing before was tweaking cache settings, or claiming that things were fixed but they weren't under conditions that users actually use the program under. They've made plenty of fixes and improvements in real world scenarios - the problem is more that they keep adding new things that take up more memory than they've saved (The javascript JIT, for one, caused a huge increase in memory usage). The other big problem is they've only ever caught a narrow range of problems. Lots of memory degradations from new features slipped by their automated testing because it's only run with a single tab open. And they only ever caught "true" memory leaks, where memory would never be freed - if memory wouldn't be freed until closing Firefox, it's no different to the users, but it never would have been caught. You can see the results of the work they've been doing to help find memory issues by opening up about :memory. The level of detail available is incredibly helpful for narrowing down issues, so I expect we'll continue seeing big improvements in memory usage for a number of releases to come.
|
#
¿
Sep 8, 2011 05:54
|
|
|
|
| # ¿ Apr 27, 2024 15:06 |
|
|
The versioning number change is about getting users to update more quickly. The idea is that users are much quicker to update with major version number changes, and the versioning they'd been using understated things - Firefox 3.0 was end-of-lifed a full year before Firefox 4.0 was released. Now that they've finished working on making it look more like Chrome, they have been making a lot of progress on reducing the RAM usage. Edit: also, I'm rather appreciative of all the effort spent making firefox use vertical space more efficiently when using a 1366x768 laptop. Edit 2: This graph makes me sad http://gs.statcounter.com/#resolution-ww-quarterly-200901-201103 Zhentar fucked around with this message at 18:33 on Sep 13, 2011 |
|
#
¿
Sep 13, 2011 18:28
|
|
|
On the General tab of the Options form, set 'When Firefox starts:' to 'Show my windows and tabs from last time'.
|
|
#
¿
Sep 21, 2011 22:36
|
|
|
The change is in response to a considerable negative response to the "blurry" text rendering in Firefox 4. Firefox 6 improved the renderer so that the font rendering mode could be picked, and 7 changed the default rendering mode for most fonts. It's also ironic that you call the kerning "linux'y" because it's using the same "GDI Classic" rendering mode used by almost all windows software (and what Firefox used before 4).
|
|
#
¿
Sep 27, 2011 22:59
|
|
|
Microsoft Spy posted:Why? I think we make it pretty easy.
|
|
#
¿
Sep 28, 2011 17:46
|
|
|
Alereon posted:They're working on that under the Electrolysis project, the early results of which were to break out plug-ins into their own separate process (plugin-container.exe). Unfortunately Mozilla's development process doesn't really allow outsiders to follow along because it's so bug/mailinglist-centric, so it's hard to track the progress. That's not quite what Electrolysis is (although it is necessarily a part of Electrolysis, it can be done completely independently of it, and they have been making some progress on it over time). As far as Electrolysis progress, you can get a vague idea from the Electrolysis tracking bug. Obviously, it's far enough along that it Fennec has been using it for some time; from what I can gather I think the main obstacles for the desktop now are all of the desktop-related UI stuff, and add-on compatibility (a large number of add-ons will need potentially significant changes to be compatible with Electrolysis).
|
|
#
¿
Oct 12, 2011 21:33
|
|
|
Alereon posted:Can you clarify how Electrolysis is different from what I described so I know where I misunderstood? My understanding is that Electrolysis is the overarching project to break more and more tasks out of the main Firefox process. Multi-threading can be (and typically is) done within a single process. Splitting processes as in Electrolysis carries some significant benefits (reduce the scope of what's affected by crashes, improved security from restrictions on what can cross processes), but it also adds a lot of complexity to the development and adds a lot of overhead when things in different processes have to communicate with each other. Mozilla could, with comparative ease, distribute more work onto background threads within the same process, and allow greater responsiveness from the main UI thread. In my experience/opinion, Firefox's only significant remaining disadvantage compared to a certain other browser is the smoothness; even after many years of supposed improvements Firefox still stutters very frequently.
|
|
#
¿
Oct 13, 2011 23:06
|
|
|
Fangs404 posted:Looking at individual tabs, I don't think there's really a speed difference anymore between Chrome and FF, but looking at the browser as a whole, Chrome is definitely faster since one tab loading won't hold up the others. To a large extent, it won't in Firefox either. Relatively few things require blocking the main thread, and those still won't necessarily block other tabs from continuing to load in the background. I think that now the most noticeable thing that will block the main thread is garbage collection, which can really stutter things up if it's working too hard.
|
|
#
¿
Oct 14, 2011 15:46
|
|
|
Alereon posted:I generally leave it running all day without issues. It might be that a plug-in is misbehaving and consuming a lot of CPU, or it could be due to memory usage. Try going to about :memory and clicking the "Minimize memory usage" button, if that helps memory was probably the issue. If it's sluggish due to high memory usage, it's a safe bet that the minimize memory usage button won't fix it. It generally gets sluggish because there's too much that the garbage collector/cycle collector won't fix, in which case the indicator is just a very high memory usage (or just memory usage that considerably increases over the the time it takes to become slow).
|
|
#
¿
Oct 19, 2011 23:07
|
|
|
unruly posted:when a developer (group) decides that making their application multi-process isn't a priority... especially with the issues being seen now.. yikes. Multi-process != multi-threaded. All of the challenges with responsiveness can be handled either way. On paper, the multi-process solution for performance is simpler - the performance issues are may be cut down by an order of magnitude or two and become negligible, or even go away entirely. The problem is, as Mozilla has clearly realized, the details of implementing the multi-process stuff to get the "free" performance boosts actually ends up being more work than just tackling the multi-threading performance solutions. The worst part of it, is that if you think there's a lot of bitching about add-on compatibility now, Electrolysis breaks add-on compatibility in a substantial, non-trivial way. A significant portion of add-ons would require substantial changes to work at all in a multi-process Firefox.
|
|
#
¿
Nov 16, 2011 22:20
|
|
|
HalloKitty posted:Alright, but did Firefox really start up slowly for others? I have other performance issues, like one rogue tab making the whole browser unresponsive, but not startup.. A cold start up on a machine with a slow disk can be pretty bad. For many users, Firefox is the first thing they run, so it ends up paying a heavy price to initialize not only itself but a lot of system libraries. That said, the XUL.dll merge happened sometime around Firefox 1.5, so current startup performance has little relevance to the justification of libxul.
|
|
#
¿
Dec 16, 2011 22:46
|
|
|
Sprite141 posted:What I was wondering is if firefox 9, or even 8, managed to fix those issues. You'll have to try them to see. Unless you know exactly what the problem you were having was, we can't know if it's fixed. 8 & 9 work fine for most people, but so did 7. Sprite141 posted:Flash being a seperate process, and reducing the amount of crashes sounds really loving good. It is really good, but you've already got it. It's been out since Firefox 3.6.4. Sprite141 posted:Well actually I get issues with my video driver crashing every now and then, but I'm convinced it's firefox doing it. It's not (directly, at least). If it's even possible for Firefox to crash the video driver, that's a flaw in the video driver. But if your driver/video card can't handle something Firefox is doing, you can disable video acceleration in Firefox.
|
|
#
¿
Dec 28, 2011 02:10
|
|
|
rolleyes posted:I'm really hoping we get some focus on memory usage going forwards, this is ridiculous: There already has been a lot of focus on memory usage; there have been some pretty significant improvements made since Firefox 4, and there are a lot more improvements in the works. That said, Firefox needs more memory for 12 tabs than a video transcoder needs because 12 web pages are a poo poo-ton more complex than video encoding/decoding. Take a look at about :memory and you can see the kind of memory it takes to maintain the current state of many dozens of scripts running on those 12 web pages, to interpret megabytes of javascript code and make it run quickly, or to take complex HTML and CSS and transform it to what you actually see on the screen.
|
|
#
¿
Dec 28, 2011 18:16
|
|
|
xamphear posted:Am I wrong? What am I missing? When people ask me what browser to use, I say "If you don't use any fancy UI addons, Chrome is a better browser than Firefox." Is that demonstrably false? No, it's demonstrably "YMMV". My wife switched from Firefox 3.6 to Chrome because Chrome was so much faster. She switched back to Firefox 7 because she kept having problems with Flash crashing and freezing up the UI for 15-30 seconds in the process, and some general stability issues. She was surprised that Firefox 7 felt more responsive than Chrome, and it resolved the Flash crashes and has been generally more stable.
|
|
#
¿
Dec 30, 2011 20:42
|
|
|
xamphear posted:I must admit, this is the very first time I've heard anyone complain about flash locking the Chrome UI. I thought each tab being in a separate process made that impossible? Not even remotely. The processes still have to communicate with each other (and share some resources), so it's still trivial to make one process block other processes. Of course, Google's designed Chrome to try to avoid that, but it's still very possible for it to happen.
|
|
#
¿
Dec 31, 2011 03:20
|
|
|
Standish posted:Tell your router to stop returning custom error pages for DNS lookup failures. Is there a setting you can change in Firefox for when it's your ISP, not your router, screwing you?
|
|
#
¿
Jan 21, 2012 21:39
|
|
|
That would be Firefox 4. Although Firefox 9 also had some pretty good javascript performance improvements. And there are some pretty good garbage collection improvements that should be coming in Firefox 12 that will substantially reduce pauses for a lot of people.
|
|
#
¿
Feb 2, 2012 00:16
|
|
|
ryanbruce posted:If I click the little "power" button in Firebug when I'm not using it, is that good enough? Even with Firebug "suspended", everything still gets loaded into memory, so it will cause a pretty significant increase in Firefox memory usage. Worse, there's an issue that can cause it to leak a few MB of memory every time you close a window. After closing a few dozen windows and leaking, the Cycle Collector times can become pretty significant (I was able to get them to go over a second without much trouble). The Firebug issue will go away with 1.10, and the cycle collector has a bunch of huge performance improvements coming in Firefox 12 and 13 (at least an order of magnitude better, from the try build I tested).
|
|
#
¿
Feb 8, 2012 16:15
|
|
|
TOOT BOOT posted:They've been talking about improving performance for a very long time time now without much to show for it other than on paper. Arewefastyet.com was registered two *years* ago, and the browser still feels slow compared to Safari, Opera, Chrome, even recent versions of IE. Arewefastyet was very successful. Firefox 4 brought vastly improved page rendering and javascript performance, to the vast majority of users in a vast majority of cases. A lot of the exceptions have been eliminated in the releases since then. The problems, where Firefox has long suffered, lie in places that aren't so easily measured and reproduced as "this site is slow". The major focus of both Memshrink and Snappy has been in providing tools that make these things easy to measure, and pre-Snappy there was also the addition of telemetry to automatically collect real-world performance data from users. Once the tools are there, people start finding things left and right. Memshrink quickly returned some pretty dramatic results, and continues to make a lot more small improvements, and it looks safe to assume we'll be seeing the same from Snappy.
|
|
#
¿
Feb 8, 2012 20:39
|
|
|
There are potentially a lot of different reasons why it can take a long time to finish closing. One thing that I know can make it take a long time is if you have set it to clear your history on exit (in the Privacy tab in the Options window).
|
|
#
¿
Feb 16, 2012 19:38
|
|
|
Fortunately, they do seem to be recognizing it's an issue; there actually is a profile fixer on the Firefox roadmap.
|
|
#
¿
Feb 20, 2012 02:07
|
|
|
Golbez posted:So, on a modern PC, would we really gain any performance by streamlining these pages? Calculating the page layout can be a pretty significant part of page loading performance. The layout rules are really complicated, with elements affecting the size of their contents and the size of their contents affecting the elements and elements affecting other elements and it's all so complicated sometimes I'm not sure how browsers manage to achieve a layout at all, much less as quickly as they do.
|
|
#
¿
Mar 15, 2012 18:44
|
|
|
I don't know if there's a setting to undo it, but you just have to hit tab or the down arrow and it will fill the whole thing.
|
|
#
¿
Mar 20, 2012 17:29
|
|
|
TOOT BOOT posted:Didn't Google actually drop H264 as well though? This is covered pretty well in the Brendan Eich post. Google said they would, but they haven't yet. But even if they did, it wouldn't matter; most sites will fall back to playing it in Flash. Few Chrome users would ever know the difference, and they'd still be watching H264 video in Chrome and it wouldn't help push WebM.
|
|
#
¿
Mar 21, 2012 15:01
|
|
|
If you look in about:memory, you can probably get a better idea of where the problem is.
|
|
#
¿
Mar 23, 2012 14:50
|
|
|
https://areweslimyet.com has gone live.
|
|
#
¿
Apr 7, 2012 04:12
|
|
|
The biggest performance impacts from Firebug should have been fixed in 1.9, thanks to some major architectural changes. I know it at least fixed Firebug's memory leaks when it's not activated.
|
|
#
¿
Jun 1, 2012 19:55
|
|
|
Axiem posted:And it really feels to me like Firefox 13 is much more sluggish and prone to problems than 12. How do they do this They change things every release (that being the point and all). Some people have their bugs fixed, and it starts working better for them. Some people fall victim to new bugs, and it starts working worse. They try to make the latter group as small as possible, but with hundreds of millions of users, it's still going to happen no matter how well they do at it.
|
|
#
¿
Jun 21, 2012 05:56
|
|
|
Lord Dekks posted:I'm sure this has been asked many times over but didn't see anything for the last few pages. I used Firefox for years until the end of last year when suddenly it started getting really sluggish, especially switching tabs seemed a bit slow as if it had to load it from memory again etc. From my experience/investigation in the past, the problem in this case is that Firefox usually (always?) runs garbage collection when you switch tabs. There's a particular class of memory leak that can make this take a long time. In recent versions, they've both eliminated many sources of these memory leaks, but they've also made the garbage collection itself tremendously faster, so there's a good chance the problem you were having has gone away.
|
|
#
¿
Jun 22, 2012 14:52
|
|
|
jink posted:I am not getting constant crashing, but I am getting what seems to be long GC Pauses that make FF crawl for seconds at a time. These pauses get to the point that I have to close and re-open because they never recover. If you're getting behavior like that, you've got to have something leaking like mad. You can use the about :jank extension to see what's causing your pauses. That should at least help confirm that it's GC pauses.
|
|
#
¿
Jul 5, 2012 18:21
|
|
|
Firebug should have stopped leaking badly with 1.9, as far as I know. 1.10 definitely shouldn't be leaking much.
|
|
#
¿
Jul 5, 2012 21:15
|
|
|
^^^ Aurora is usually pretty reliable. It's been many months since I last ran into a significant issue with it.WattsvilleBlues posted:Honestly. The original mockups are 10 months old. Taking this length of time to land theme changes cracks me up. They aren't just minor theme changes though. They're trying to make significant UI changes in the process. People get pretty pissy when you make any UI changes (see the previous page for evidence). You want to take a long time iterating and refining before you push things out so you don't make a lot of people angry tweaking after the initial release.
|
|
#
¿
Jul 5, 2012 21:35
|
|
|
jink posted:So... how do you digest the output? Yeah, that's supposed to look more like this: code:
|
|
#
¿
Jul 6, 2012 04:53
|
|
|
LeftistMuslimObama posted:Considering that even most "power users" and IT people I know literally push the "Delay 4 hours" button on windows update for weeks at a time before finally restarting to install updates, I'd say that it's definitely too much effort for most users Firefox updates much faster, and restores to it's previous state. It's definitely a lot less unpleasant to restart for an update.
|
|
#
¿
Jul 10, 2012 23:11
|
|
|
Sunspider is too simplistic to make for a good comparison. Try something a little more complex, like V8.
|
|
#
¿
Jul 23, 2012 18:30
|
|
|
The point is... 64-bit build disadvantages: * Javascript performance 15% slower in some cases * Increased memory usage * Plugin incompatability * Memory leaks can bloat to even more ridiculous numbers 64-bit build advantages: * Doesn't crash if you actually need > 3GB of virtual address space * ???
|
|
#
¿
Jul 23, 2012 21:02
|
|
|
NihilCredo posted:I am pretty incredulous that Chrome would feel less responsive to you than every other browser, including multiple *foxes. That benchmark seems to agree with me on that, too. There's a pretty big difference between javascript performance and responsiveness. Failure to understand this for a long time is a good part of why Firefox fell so far behind Chrome in responsiveness for most users. On a different topic, the FF15 update has screwed up my text rendering. My searching hasn't turned up any evidence that they changed anything, though. Does anyone know what's different?
|
|
#
¿
Jul 23, 2012 21:07
|
|
|
Aleksei Vasiliev posted:As far as I know, memory fragmentation is the main reason FF slows down the longer it's open and being used. It's not. As long as it's not swapping to disk, memory fragmentation will have pretty much no performance impact.
|
|
#
¿
Oct 12, 2012 18:04
|
|
|
Your session from the previous time you closed Firefox is saved as sessionstore.bak in your profile directory. If you haven't started firefox twice since then, you can delete the current sessionstore.js and rename the .bak to .js (and copy off both somewhere else before you start messing with them, in case you screw up...)
|
|
#
¿
Nov 15, 2012 01:41
|
|
|
|
| # ¿ Apr 27, 2024 15:06 |
|
|
jink posted:I used to have these problems as well. I think it's related to the Garbage Collection of memory going wild and locking up the UI thread. GC pauses should pretty much never be more than a brief stutter these days; they've made a number of huge improvements to the performance of it in the recent releases. These days, long pauses are either going to be plugins (like flash) or from seriously bad disk performance.
|
|
#
¿
Nov 29, 2012 18:17
|
|