10 Things Apple Did To Make Mac OS X Faster
bariswheel writes "This kernelthread article seeks to investigate further to the inner core of OS X and the improvements therein. The subtopics are the following: BootCache, Kernel Extensions Cache, Hot File Clustering, Working Set Detection, On-the-fly Defragmentation, Prebinding, Helping Developers Create Code Faster, Helping Developers Create Faster Code, Journaling in HFS Plus, and Instant-on."
OS X is the only OS I"ve ever installed that subsequent versions speed up my older computers. Amazing... I'm waiting for an Apple Intel Tower and I'll retire my G4 Tower.
Damn ADC interface.. what am i to do with this big ass cinema display?!?!!?
what about Linux? Could it obtain benefits implementing some of the improvements made into MacOS X? I've heard about BeOS and the incredible perfomance due to multithreading, it's very dificult to adapt an BeOS kernel to the Linux features (multiuser, drivers...) maintaining the perfomance?
I updated from Panther(10.3) to Tiger(10.4) and my machine seemed slower. I decided to do a fresh install, and things improved, as always the fresh install is better than an update.
I still think that Panther was running a bit faster tahn Tiger, maybe it is the widgets..........
silly widgets!
This was all done on a PowerBook G4(TiBook).
The current posters often miss dupes within the same day
I am not sure you can blame the posters, often two people post the same story before either is listed on the site. Even if one is already there, surely it's the editor that's at fault not the poster?
Common sense is not so common
Linux gets faster too.
Kernel 2.4 to 2.6 was a pretty big jump in speed. I just upgraded to the latest KDE and a bunch of other updates, and got another performance jump. Once they shake the bugs out of the Radeon drivers for X.org, I'll get accelerated X, and another big speed boost.
In fact, of the major OSs, it's pretty much only Windows that keeps getting slower.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
I'll tell you what happened: somebody submitted this old story to Digg and a Digg reader then submitted it here. (I have noticed that many stories appear at Digg first, which is why I read Slashdot once a day now, and Digg now has Slashdot's old spot on my link toolbar in Firefox.)
It used to be that OSX had a brain-dead ABI that resulted in not all of the PPC registers being used 'properly', in order to maintain a 68k 'compatability' mode ..
Has this been changed? Are all the registers of the PPC being used properly now? Is the PC register actually being used as a program counter, rather than one of the generic 32-bit registers?
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
It wont, and I've already bought more memory for myself. Been there...saved up.
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
The HFS plus approach seems like a good idea, but I'm wondering if there is a performance cost, both in CPU cycles and drive wear and tear. It also looks to me like the system could be defragging files that are already contiguous, but I may be wrong. Given that modern journaling filesystems (supposedly) are not likely to become fragmented in the first place, is this feature worth it?
Ideology: A tool used primarily to avoid the bother of thinking.
since I screwed up, here's the rest:
e nts" which now expands their one collumn to occupy most of the window.
I'm not sure I agree with all or even most of his points of contention.
In issue 1 for example he complains that each open/save dialouge starts out the exact same way and then goes on to complain further in the article that the OS isn't always consistant. It's consistant for each dialouge to remain the same size by default until the user specifies a change. Furthermore since the size of the dialouge can be set per application, that size would need to be specified by the application making having a universal override obnoxious.
In his 2nd point he's descirbes a senario which is at best extremely uncommon and then describes a process which is obnoxious and complicated when it's easier for most people to either have an automator script to open specific things they want or even better for his senario and automator script which asks where he is and then opens the appropriate applications. A simple applescript for the applications one doesn't need all the time with a prompt at the begining to ask whether to launch the remaining apps and then placing that script in the login items folder seems more useful and less annoying than check boxes to enable and disable each item that you must do before loging out the previous time.
point 3 he's correct on
point 4 he's correct on the disapearing sidebar but on the issue of double clicking the boarder, it's a rather difficult task to accomplish accidently so I am sure anyone doing it would notice the dimple before and after.
point 5 he's moving away from his consistancy argument again. With the column view you set the size of the columns and the number of columns, and if you chose to physicaly change the display you can. What he's suggesting is a display system which dynamicaly changes size to fit the content of the display which while it could be benneficial to some people seems overly complicated and a major violation of the consistancy guideline. It's concieveable to see a situation there where all of a sudden you would go from having 4 collumns displayed to having 2 or 1 because you have one file in the display such as "com.apple.Components2.LocalCache.QuickTimeCompon
point 6 he's correct on
point 7 he's got a point but at the same time, with the addition of the PDF abilities and the fact that faxing IS handled with PDFs it does make sense to put it under the PDF button. In the end I don't find it much more of an abstraction than his recomendation to make it an availible printer.
point 8 I can see a method to the madness in that if the next set of startup items require the server, it's important for you to know that the server is not availible BEFORE those apps launch and fail. There may be a better way, but I don't agree that it's a failing.
in point 9 the views update for the column view I think is a good thing. While it's not 100% consistant, in this case it would be irritating for a directory I'm working with to rename and then immediately move out of my working view until I indicate being done with the directory either by being idle or moving to a new object.
The size information I would assume is an updating routine thats scheduled rather than called.
in point 10 if he cant see a situation where a user might unknowingly or mistakenly change their file extention then he needs to think harder. The checkbox would be nice though but it's also nitpicking at this point. It's a potentialy destructive action, and a user should be reminded to think before they do it. Being able to permanently dismiss such reminders is what gives viruses and other malicious programs a better chance of succeeding.
T Money
World Domination with a plastic spoon since 1984
Doesn't Apple use gcc?
I know gcc itself improved a very great deal over the same time period, and I have always assumed that the speed gains were (largely? mostly?) due to that, rather than wondrous new algorithms on Apple's part.
Linux and KDE sped up a lot too, over the same timeframe.
Mods: parent is not a troll or flamebait, he's just stating an opinion. That said, he's wrong (IMO), but that's no reason to mod him down. Posts like his are useful in that they further informed and relatively civilized debate.
I much preferred Mac OS back in the OS 9 days. OS 9 screamed in comparison to OS X. It had its problems, sure, but at the time it was the only mainstream OS that was not built on technology besides itself.
If you've ever developed for Mac OS 8/9, you'd realize just how serious those problems were. I wrote part of a printer driver for OS 8/9, and it was hell. Memory allocation was an utter mess. Printer drivers *should* just run in userland, and be unable to muck with the kernel, but that's not how things worked. The driver had full access to both the system memory space and the memory space of whatever application called it. It was preferable to allocate from the application's memory space, but we didn't have that freedom. Because of the stupid user-controlled memory allocation system, we had to worry about how much free memory any application might have been given by the user, and make sure we didn't use more than that. We were trying to modernize the UI and make it more flexible, so we used Metrowerks PowerPlant (an application framework). The problem was this increased our memory requirements to the point where we couldn't fit in the 100kB or so of free memory SimpleText would have by default. To work around this, we would allocate from the system heap. This came with its own problems--if you accidentally wrote to a null pointer, you overwrote the debug traps, and crashed hard. It made for wonderful time in debugging, and forced me to very quickly learn to be careful with pointers and memory allocation (this was my first programming internship, BTW).
Then there was all the cruft left over from the Mac OS's Pascal roots... Pascal strings, pascal calling conventions. And the memory management--Handles!--ugh!
OS 8/9 was a pain in the ass to develop for, whereas OS X is much easier. That's why we're seeing so much great new OS X freeware and shareware.