5 ms·
> As the author mentions, once you get to 3x-6x more physical ram than what you absolutely need, the garbage collector no longer slows down your device - in fac
by weland 13y ago
> As the author mentions, once you get to 3x-6x more physical ram than what you absolutely need, the garbage collector no longer slows down your device - in fact, it speeds it up. So I'm not sure that this is really that big a problem. RAM is one of the areas where mobile devices really are improving rapidly
That's not generally true. GC performance decreases with the number of objects that have to be collected. More objects (and real-life experience shows that as soon as there is more of a finite resource -- memory in this case -- users' demands will quickly lead to ti being depleted again) actually means worse performance, not more.
GC also depends heavily on the memory's speed, and on the speed of the CPU-memory interface. If those remain constant (and, again, real-life experience shows that, while they don't, they tend to get faster slower than the CPUs do), GC performance hits will actually become heavier with increased memory.
This is particularly important if you consider that you can't actually force GC in most web environments. It's up to the system to decide when it starts cleaning. If that's done on a worst-case basis (i.e. postpone collection until the memory use becomes, or looks to be on a track of becoming dangerous), increasing the amount of memory won't help for memory-intensive applications.
- jamesaguilar 13y agoPer-pass performance gets worse. Overall performance gets better, because fewer passes need to be made.
- weland 13y ago> Per-pass performance gets worse. Overall performance gets better, because fewer passes need to be made. Yes, but what the users will see is that, instead of his application occasionally "feeling funny" every five minutes or so, the application will visibly lock every ten minutes. It's a hard lesson that Java learned a long time ago: it's ok to be reasonably fast all that time, but people will immediately begin yelling if you're fast most of the time, but suddenly you get really sluggish, even if just for a few seconds.
- rsynnott 13y agoWhich is to a large extent why Java GUIs were essentially a failure, but it still has a large niche in high-performance server apps; you can usually get away with >100ms pauses there.
- pjmlp 13y agoActually I think it was more related to: - sloppy programming, the same kind we see nowadays in JavaScript - doing everything in the main thread - not caring to learn how to use Swing properly - not even taking the time to switch to the native look and feel - not caring about users and providing a rich UI experience
- mhd 13y agoWell, it was an enterprise language, and quite often most of the flaws you'd get in Java GUIs were there in the previous, native versions, too. Just like they're still there in the intranet web apps that replaced a few of the Java clients. (I know a few people who still prefer the old-fashioned mainframe terminal apps, if available. If all you have is a few colors and line-drawing characters, even programmers have a hard time messing up simple forms. Not saying that we/they don't often succeed despite this difficulty...)
- weland 13y agoNah, the lesson I was thinking about was taught earlier, in the days of AWT. Back then, Java was fairly slow, and the garbage collector was not as sophisticated as today. When the GC started collecting, you knew.