However, it's still early days. It might just be a "washed car effect."
(Mac Pro 1,1 / 7GB RAM / WD Caviar Black)
231–240 of 269 posts
However, it's still early days. It might just be a "washed car effect."
(Mac Pro 1,1 / 7GB RAM / WD Caviar Black)
Earlier quoted context omitted.
Garbage collection does not have to mean GC as we know it from Java. It's not that the objects created by the app are garbage collected. The whole memory management in modern systems resembles a GC (it pretty much is a GC). Just instead of managing liveness of the objects, you manage the block mapping. Sometimes you have to write them back to the disk, sometimes you have no memory left and you have to swap them out..…
When he says "the garbage collection algorithm may require that all of a program’s data be in physical RAM before collection can happen," it sure sounds like he's talking about in-app heap collection. Does "may require that all of a program's data be in physical RAM" really apply to the kernel level of memory management? It makes no sense to me when applied that way.
The only winners are those "Mac cleaner, keeper" apps whose Google Ads know we are all watching beach balls.
Earlier quoted context omitted.
Yes, I am a fan of ML so far too. Given that Apple has fixed none of my reported bugs in 10.7, but I can't reproduce many of them in 10.8, I wonder if it even makes sense to analyze 10.7 anymore - seems it's a done deal for Apple.
This is very good news indeed. I'm okay that they don't backport bugfixes as long as ML comes out in a reasonable timeframe.
Earlier quoted context omitted.
exFAT is Microsoft proprietary shit.
The problem isn't with exFAT, it is with fsck_exfat, which I'm fairly certain Microsoft didn't write. chkdsk on Windows manages to clean exFAT volumes just fine without using up 8gb+ of memory.
I've gotten a lot of his symptoms, and there might be another cause: http://reviews.cnet.com/8301-13727_7-20064489-263.html Bad blocks in the disk, causing the system to beachball frequently due to disk I/O failures when swapping out to disk. The solution for me was to back up, reformat the disk and zero-ing out everything causing bad sectors to get remapped, and then restore.
Problem resolved. Not that I don't still get inexplicable pinwheels, but nothing like before.
Earlier quoted context omitted.
"It's definitely getting slower but that's expected since it's such an old system." I see this sentiment a lot, but I disagree with it. What are "iTunes, Xcode, Safari/Chrome, and a mail client" doing now that they weren't doing four years ago? Is it enough to justify their latest versions feeling less responsive than their versions from four years ago?
I think that as the developers are developing them on better hardware they pay less attention to performance. For example you wouldn't expect the lastest build of iTunes, or OS X to run on hardware for 10 years ago. As system specs improve developers seem to pay less attention to performance & file size. It seems crazy to me that modern web browsers are over 50mb in size. But as hard drive size isn't really a constra…
font-size: 16px; line-height: 1.5em;
Earlier quoted context omitted.
Yet it still swaps to disk ALL THE TIME and a new Terminal.app window can take up to 5 seconds to open. That's not swapping. That delay is /usr/bin/login searching the system logs so that it can display the date and time of your last login. Create a .hushlogin file in your home directory to prevent that.
You sir are a gentleman and scholar. As a laptop user with only 8 GB of RAM and a slow non-SSD hard disk, this one trick just made my day! Thanks.
There's a nice script[1] for tweaking OS X's dynamic pager settings to reduce the system's swappiness that helps a bit. Incidentally, if you have both an SSD and HDD installed, you can use it to move the swapfiles to the HDD to reduce wear. [1]: http://dropsafe.crypticide.com/article/3848