[moki]

There's been quite a bit of discussion lately about the speed of OS X. It is certainly true that OS X is slower than OS 9 on the same machine, and Ambrosia's el Presidente, Andrew Welch examines why.

The article explains in layman's terms why OS X is slow, and debunks a number of myths and scapegoats concerning OS X's speed. It also presents some of the technical hurdles faced by Apple and third party developers concerning OS X.

You can read the full article here:

http://www.AmbrosiaSW.com/news/newsletter/

[gorgonzola]

Very nice article, Andrew.

It's nice having OS X Developers around to give some solid reason to what is otherwise speculation (and hey, if it's El Presidente, it doesn't hurt either ).

One sort of OT question ... do you happen to know whether Carbon will be able to access Services at some point in the future? That's a big feature that Carbon still doesn't have access to, and unfortunately I don't hear it mentioned much. (I have written to Apple about that, of course.)

[theolein]

Thanks Andrew,
the first clear article I've read on OSX. Gives me motivation again. Now if I can find a job.....

[Scott_H]

In any event, like most people who are using OS X, I've been a bit dismayed about the performance of our shiny new operating system. The truth of the matter is that there is no single thing that is causing OS X to be slow. In order to speed up OS X, a myriad of small tweaks and optimizations need to be made to every level of the operating system (especially the event dispatching mechanism, I believe).

I agree. As I've been posting about this since using OS X. It's good news because there's no reason why littlest of iMacs can't smoke that stuff through the CPU.

Get to work Apple!

Oh and Rage Pro drivers. That's key too.

[edddeduck]

Cheers Andrew

I am reading right now....

[Scott_H]

Not as "in depth" as I had hoped for. The geek in my wants more!

[foobars]

Good article, but nothing new- all this stuff has already been discussed here...

[moki]

Originally posted by gorgonzola:
<STRONG>
One sort of OT question ... do you happen to know whether Carbon will be able to access Services at some point in the future? That's a big feature that Carbon still doesn't have access to, and unfortunately I don't hear it mentioned much. (I have written to Apple about that, of course.)</STRONG>

You know, I have no idea if services will be made available to carbon apps. I'm also not sure if it is important or not. Services allow apps to export a single feature to other applications.

If you make your apps AppleScript-able, you can export all kinds of functionality. The same kinds of things that are done with services could be done via AppleScript -- there could be a specific type of functionality you export from your app to have it listed in the "services" menu.

[moki]

Originally posted by Scott_H:
<STRONG>Not as "in depth" as I had hoped for. The geek in my wants more!</STRONG>

Well, I tried to make it readable -- what more do you want to know? If you have any specific questions, and I know the answer, I'll give it a go.

[Millennium]

Services allow apps to export a single feature to other applications.

Not true. Though it's not as simple to do, you can have a program export many features through Services. Take a look at Grab, TextEdit, and Mail for examples of these.

If you make your apps AppleScript-able, you can export all kinds of functionality.

Only to a point. See below.

The same kinds of things that are done with services could be done via AppleScript -- there could be a specific type of functionality you export from your app to have it listed in the "services" menu.

For "standard" services, you are correct. This doesn't hold, however, for filter and "spell-checker" services (one might assume that that last type of service would be possible to use for more than just spellcheckers, though; perhaps a reincarnation of the ultra-cool IcEtE?) You can't do those in AppleScript. Nor could you do what Apple calls "add-on services," which allow you to export some functionality without having to launch the full app.

In the end, Services are very important, I think. I'm not sure how feasible it is to implement them in a non-OO paradigm, but I certainly hope Apple makes it possible, if only for the sake of better integrating the two API's.

[theolein]

Originally posted by Millennium:
<STRONG>
In the end, Services are very important, I think. I'm not sure how feasible it is to implement them in a non-OO paradigm, but I certainly hope Apple makes it possible, if only for the sake of better integrating the two API's.</STRONG>

Via DSO's ala Apache or shared libraries? I mean it has nothing as far as I can see , to do with a OO system, but rather with a runtime system that can load objects as requested (correct me if I'm completely wrong). If Apple implemented a hook so that carbon apps would see the available objects as so's or sl's then it would surely be possible. In OSX there is already something similar with the Java-Cocoa bridge. Also Java can, via JNI, use native code , both c and c++ ,albeit with c being more complex, and native code can get functionality from Java objects. So I think this could be possible with ObjC's runtime as well.

[mudmonkey]

You know, I have no idea if services will be made available to carbon apps. I'm also not sure if it is important or not. Services allow apps to export a single feature to other applications.

Andrew, Cocoa apps that export services are actually exporting the object so that it is available in the other thread's space. Though, not impossible, the services seem to very much rely on the dynamic runtime environment that Obj-C or Java provide. I can't imagine that there is a way that they could implement it in Carbon.

Hopefully, eventually, people will move away from the functional nature of Carbon...

[utidjian]

That was a very well written explanation... especially the part about all the programmers "getting up to speed" with the new code. However, my question is... how come the LinuxPPC variants are SO MUCH faster on less RAM. Is Linux "doing less"... is it "using less RAM"... is it "just more efficient"... From my tests it even runs Classic (using Mac on Linux, MOL) faster than OS-X. Why is that.

It may be trying to compare Apples and Oranges but in this case they are both fruit.

[moki]

Originally posted by mudmonkey:
<STRONG>Andrew, Cocoa apps that export services are actually exporting the object so that it is available in the other thread's space. Though, not impossible, the services seem to very much rely on the dynamic runtime environment that Obj-C or Java provide. I can't imagine that there is a way that they could implement it in Carbon.

Hopefully, eventually, people will move away from the functional nature of Carbon...</STRONG>

yep, I'm aware of how the services work. What I'm saying is that the *functionality* provided by Services could be duplicated rather easily using AppleScript.

I also am not one of those people who believes that "objects are everything". Procedural and object-oriented programming are both valid approaches to the same problem; both have their upsides and downsides.

[Kosmo]

Like I've said before, if anyone knows it Andrew.

Thanks for the info Andrew, I guess it's now a question of 'when' the speed will arrive, not 'if'...

And we wait...

[moki]

Originally posted by utidjian:
<STRONG>That was a very well written explanation... especially the part about all the programmers "getting up to speed" with the new code. However, my question is... how come the LinuxPPC variants are SO MUCH faster on less RAM. Is Linux "doing less"... is it "using less RAM"... is it "just more efficient"... From my tests it even runs Classic (using Mac on Linux, MOL) faster than OS-X. Why is that.
</STRONG>

It's a combination of both things. Linux is doing less in some areas (it's possible OS X is trying to do too much in some areas, too), and also, Linux has had more time to become more optimized than OS X is.

[ 06-20-2001: Message edited by: moki ]

[booboo]

Originally posted by utidjian:
<STRONG>However, my question is... how come the LinuxPPC variants are SO MUCH faster on less RAM. Is Linux "doing less"... is it "using less RAM"... is it "just more efficient"... From my tests it even runs Classic (using Mac on Linux, MOL) faster than OS-X. Why is that.....</STRONG>

This is most definitely my question too - if it gets overlooked here, please start a new thread. I had written a lengthy post on the subject myself, but having read your post, I'm circumvented! I offer just one paragraph...

...and others have suggested that Quartz is not a key part of the problem. If you take away Quartz you're left with a UNIX variant on PPC. Are there any other UNIX based variants that run on PPC? What about Linux? A not too distant cousin. It doesn't have Quartz, but has many other OS-X-like features. How zippy is it on the same hardware? Or is OS-X fundamentally too different for this to be a fair comparison?

[mudmonkey]

yep, I'm aware of how the services work. What I'm saying is that the *functionality* provided by Services could be duplicated rather easily using AppleScript.

But, with Applescript you seemingly would end up with something quite different. It is akin to CORBA vs. IPC. You could make functional apps access CORBA objects with IPC, but, it sure is convoluted.

I also am not one of those people who believes that "objects are everything". Procedural and object-oriented programming are both valid approaches to the same problem; both have their upsides and downsides.

Which is why ObjC is so great! I just believe that Carbon is not the future of the MacOS API. This isn't a Cocoa vs. Carbon, it is that I have a feeling that once the Carbon API is solid, Apple will "leave it be."

[mudmonkey]

That was a very well written explanation... especially the part about all the programmers "getting up to speed" with the new code. However, my question is... how come the LinuxPPC variants are SO MUCH faster on less RAM. Is Linux "doing less"... is it "using less RAM"... is it "just more efficient"... From my tests it even runs Classic (using Mac on Linux, MOL) faster than OS-X. Why is that.

Question for you: Does X-Windows feel faster than Aqua to you? X-Windows is quite slow (in my opinion), and Aqua is no slower.

My non-graphical, rudimentary tests with Darwin vs. LinuxPPC show Darwin with a slight edge. These were tests with my own research application, running millions of scenarios. I have a G3, so, there was no Altivec optimization.

[moki]

Originally posted by booboo:
<STRONG>...and others have suggested that Quartz is not a key part of the problem. If you take away Quartz you're left with a UNIX variant on PPC. Are there any other UNIX based variants that run on PPC? What about Linux? A not too distant cousin. It doesn't have Quartz, but has many other OS-X-like features. How zippy is it on the same hardware? Or is OS-X fundamentally too different for this to be a fair comparison?</STRONG>

Just blaming one sub-system (such as Quartz) isn't going to do it. Think about it this way: there are thousands of components working together under OS X. It can only be as fast as the slowest part of the component chain, and each link in the chain slows it down further.

What needs to be done is proper profiling on what areas are slow, and why. This is something that I'm assuming is being done as I type this, at Apple.

From what I've observed, I would say that there are just lots of places where Apple tried to get things working without regard to performance. This all adds up.

I don't think there is one component that is slow. I think they are all a little slow/unoptimized -- each one on their own wouldn't be so bad -- but the cumulative effect of all of the little inefficiencies is an OS that is slower than it should be.

[moki]

Originally posted by mudmonkey:
<STRONG>

Which is why ObjC is so great! I just believe that Carbon is not the future of the MacOS API. This isn't a Cocoa vs. Carbon, it is that I have a feeling that once the Carbon API is solid, Apple will "leave it be."</STRONG>

I agree that Objective C is cool -- I far prefer it to C++ (and the way most people write C++ code really amounts to the same functionality Objective C provides).

I'm pretty sure Carbon is going to be around (and developing) for a long, long time, however.

[KidRed]

I don't think there is one component that is slow. I think they are all a little slow/unoptimized -- each one on their own wouldn't be so bad -- but the cumulative effect of all of the little inefficiencies is an OS that is slower than it should be.

So how much faster do you realistically believe X can get then?

[CharlesS]

Ambrosia's web site seems to be having trouble - I can't seem to load the page. It's jammed.

It's dangerous to post a link to your site on MacNN - it can sometimes take a site down faster than a denial of service attack!

[moki]

Originally posted by CharlesS:
<STRONG>Ambrosia's web site seems to be having trouble - I can't seem to load the page. It's jammed.

It's dangerous to post a link to your site on MacNN - it can sometimes take a site down faster than a denial of service attack! </STRONG>

hehe -- nah, the web site is OK. Do a traceroute, it seems like some routers along the way are not doing so well, specifically:

3 acr2-loopback.Bostonbol.cw.net (208.172.50.62) 585 ms 702 ms 660 ms

[ 06-20-2001: Message edited by: moki ]

[one]

Originally posted by moki:
<STRONG>There's been quite a bit of discussion lately about the speed of OS X. It is certainly true that OS X is slower than OS 9 on the same machine, and Ambrosia's el Presidente, Andrew Welch examines why.

The article explains in layman's terms why OS X is slow, and debunks a number of myths and scapegoats concerning OS X's speed. It also presents some of the technical hurdles faced by Apple and third party developers concerning OS X.</STRONG>

Excellent article, Andrew! Thanks for providing a little common sense to the tirade - I mean, the debate

I especially liked this part:

There are two approaches you can take as a developer: you can become frustrated that things have changed, or you can can embrace the adventure that is OS X. There is some seriously cool stuff in there to play with; beating your head into a wall trying to do things the old way will prevent you from seeing that.

I know you were speaking as a developer to developers, but it applies no less to us users (the Mac 'community'). Most of the flame wars seem to be between those who plan to enjoy the ride and those who refuse (much like rollercoasters, I suppose).

[Drizzt]

I tend to believe that those who speak the loudest are the one who knows the smallest. Thank you for providing us a great tool to make them understand what is, and what is not.

[ndptal85]

Many Unix's run on PPC. AIX, Linux, FreeBSD, NetBSD, OpenBSD, Darwin and Mac OS X. Linux runs faster than Mac OS X because Mac OS X has a heavy GUI weighing it down, Aqua. Linux or any *NIX doesn't have a GUI until you bother to put one up. If you were to install Darwin alone there wouldn't be any speed problems.

Just for fun you can see an entirely Unix environment by logging out of OS X and logging back in as userneame "&gt;console" password "whateveryourpasswordis" and you'll see what most *NIX folks work with. To get out of there just type in "exit".

[foobars]

Originally posted by ndptal85:
<STRONG>Many Unix's run on PPC. AIX, Linux, FreeBSD, NetBSD, OpenBSD, Darwin and Mac OS X. Linux runs faster than Mac OS X because Mac OS X has a heavy GUI weighing it down, Aqua. Linux or any *NIX doesn't have a GUI until you bother to put one up. If you were to install Darwin alone there wouldn't be any speed problems.

Just for fun you can see an entirely Unix environment by logging out of OS X and logging back in as userneame "&gt;console" password "whateveryourpasswordis" and you'll see what most *NIX folks work with. To get out of there just type in "exit".</STRONG>

Three things:

1) You mean Quartz not Aqua. I don't think OSX problem is water retention.
2) Quartz is not slowing OSX down (it is very efficent as window managers go).
3) The core of OSX is just as fast with or without Quartz. Things work nearly as quickly through console.app as if you were to turn off the window manager.

[Gee4orce]

Well I read the article, but I fail to see what areas of Mac OS X are being blamed for the slow speed. According to the article, most parts of Mac OS X are pretty decent speedwise.

Is this just a case of the whole being less than the sum of the parts ?

Me - I'm working through Learning Cocoa, and I tell you, I wrote a Mac application in 10 minutes last night that would have taken me 10 weeks to write back in 1991 (when I was a Mac programmer). Now that is a different kind of speed...

[utidjian]

Originally posted by booboo:
<STRONG>

How zippy is it on the same hardware? Or is OS-X fundamentally too different for this to be a fair comparison?</STRONG>

I have not tested it on the same hardware yet. I have LinuxPPC (SuSE-7.0) running on two iMac-DVs each with 128M of RAM. These machines are dual boot with OS9.0.4. On one of them I loaded every app that came on the six SuSE CDs which took up 5G of disk! The other I kept a bit more conservative. I also loaded the Aqua-DR16 etheme which gives the iMacs the same, for the most part, "look and feel" of OS-X. That is to say most everyone thinks it is OS-X they are running. These machines are quite zippy. LinuxPPC "feels" faster than even OS9.0.4. The Enlightenment/Gnome combination is not a lightweight window manager in the Linux world. These machines have had no crashes or lockups or kernel panics in the 5 months since installing LinuxPPC.

I have OS-X/OS9.1 (now 10.0.3) loaded on a brand new dual 533MHz G4, nVidia graphics card, CD-RW, and (originally) 256M of RAM. OS-X was an absolute dog compared to LinuxPPC. I doubled the RAM to 512M and it's speed is (how it "feels") is MUCH improved though still a little slower than LinuxPPC. I have not installed LinuxPPC on the dual G4 yet because it doesn't support the nVidia card yet. Linux does support nVidia cards on x86 and the performance is "scintillating".

[Clive]

Originally posted by Millennium:
<STRONG>
For "standard" services, you are correct. This doesn't hold, however, for filter and "spell-checker" services (one might assume that that last type of service would be possible to use for more than just spellcheckers, though; perhaps a reincarnation of the ultra-cool IcEtE?) You can't do those in AppleScript.</STRONG>

Perhaps I'm missing the point completely here? For what reason can't you write a spell checker in AppleScript? I'm pretty certain I could do it, though it might not be the fastest thing in the world (I've certainly written search and replace routines with AppleScript, complete with GUIs - see DialogDirector).

[DannyVTim]

I've been stating what is in the article all along. People seem to want to blame something and in turn come up with the magic bullet that will fix the problem. If common sense starts to get the better of them, they say apple has secret builds and secret line of development.
I think it's just a matter of time before they find bottlenecks and free them up. However, people expect or want that right away, so they refuse to use common sense. It's everything in the article common sense? It's just a matter of time. I have to say a minor bug release like.10.0.4 has provided minor but noticeable speed increases for my B&W G3 300. I'm sure in a year form now it will be even faster. And, I expect that in time it will be almost as fast as 9 in many ways and faster in many other ways.

For an example of how X is already fast in some areas then 9, load about 30 JPGs in nine and then in X. X is obvious faster at decompressing the images.

[foobars]

I'm surprised nobody here has mentioned the stock MathLib Apple is using for OSX right now...

Optimize that and you get a free speed boost accross the board.

[DannyVTim]

what exactly is the problem with mathlib?

[SillyMonk]

Originally posted by foobars:
<STRONG>I'm surprised nobody here has mentioned the stock MathLib Apple is using for OSX right now...

Optimize that and you get a free speed boost accross the board.</STRONG>

You are telling people to recompile all their code? Or are you talking about a different mathlib than is used in compiling software?

[c0rvette]

Originally posted by moki:
<STRONG>

hehe -- nah, the web site is OK. Do a traceroute, it seems like some routers along the way are not doing so well, specifically:

3 acr2-loopback.Bostonbol.cw.net (208.172.50.62) 585 ms 702 ms 660 ms

[ 06-20-2001: Message edited by: moki ]</STRONG>

There was a HUGE thunder/lightning storm here in boston that day.

[charleschuck]

The article mentions that the scheduler does allow the use of getpriority / setpriority by developers. However, all I've ever heard on the Darwin mailing list is that the version of mach in 10.0.x won't acutally use priorities set. That is to say, you can use setpriority to tell a process to run at a given priority, and that mach remembers the priority number given to it, but it will ignore it in acual scheduling use.

Any clue where it's stated that setpriority acutally does work?


Chuck

[foobars]

Originally posted by DannyVTim:
<STRONG>what exactly is the problem with mathlib?</STRONG>

The math librarys that OSX developers currently use are very generic in the sense that they are old and were designed to be used with software that could be portable accross platforms. This basically means many math operations don't take full advantage of PPC processors- making programs somewhat less efficent. A rewrite of the libs specifically for PPC processors could help speed things up, or at least would help programs run a little smoother.

[Richard Clark]

Thanks for the article Andrew!

Optimization is going to be key. No doubt about it. It's nice to see OS X through a developers view point.

I'm a technician for a good size company. Speed is going to be very crucial for us to get the work out at a decent pace for our catalogs. But the one thing that we can do and something I HIGHLY recommend is to purchase more RAM.

My machine here at work (G3 Beige) has 190 MB. It works but isn't the greatest with X. Most of the machines here that aren't G4's are G3 Beiges with 100 MB or less.

Mine at home (G4/450) has 768MB and does well. I realize that the two configurations (work and home) is like comparing a Lotus to Pontiac. The one thing though that they have in common and will affect performance is RAM.

I know some of you will point out that virtual memory is on and takes care of tasks on demand. That's all good and well. If the minimum requirements are met OS X will run. But the more RAM a machine has the less hard drive space is used and the faster OS X will run.

Is it overkill for me to have 768MB RAM at home? Not in my mind when working on graphics and a large number of tasks all at once. Also, the 512 MB DIMM just purchased from Data Memory Systems was $144.00. Not too bad. Just to get a machine up to 256 MB will have OS X working well. That's where my machine at home was at running X for about two and a half months.

The point is that I agree with Andrew about when OS X is optimized and sped up that will help alot. Couple that with some enhancements made to the system like adding a little RAM and X is going to smoke!

[Kate]

Originally posted by Richard Clark:
<STRONG> But the more RAM a machine has the less hard drive space is used and the faster OS X will run.
</STRONG>

Sorry, that is one of the myths already wrapping around Mac OS X. There is no functional speed gain by adding memory. Only if you get to the point where constant swapping is bringing the system down, i.e. when opening lots of programs and opening plenty content rich windows, some RAM will help to avoid that.

Adding 2 x 512 MB RAM in addition to my 128MB bar and removing these shows no side effects during my tests. No menu, no window, no butten reacts smoother, snappier or quicker, no file copy process, no application start and no system boot time gets any measurable speed boost.

The speed hits are in general not memory related and therefore cannot be cured by adding insane amounts of it. Do not mismatch a sluggish system with an overloaded swapping system! The latter can be helped by adding RAM, the former can be helped by skilfull programmers.

[Kate]

Originally posted by Richard Clark:
<STRONG> But the more RAM a machine has the less hard drive space is used and the faster OS X will run.
</STRONG>

Sorry, that is one of the myths already wrapping around Mac OS X. There is no functional speed gain by adding memory. Only if you get to the point where constant swapping is bringing the system down, i.e. when opening lots of programs and opening plenty content rich windows, some RAM will help to avoid that.

Adding 2 x 512 MB RAM in addition to my 128MB bar and removing these shows no side effects during my tests. No menu, no window, no butten reacts smoother, snappier or quicker, no file copy process, no application start and no system boot time gets any measurable speed boost.

The speed hits are in general not memory related and therefore cannot be cured by adding insane amounts of it. Do not mismatch a sluggish system with an overloaded swapping system! The latter can be helped by adding RAM, the former can be helped by skilfull programmers.

[unimacs]

Originally posted by Kate:
<STRONG>

Sorry, that is one of the myths already wrapping around Mac OS X. There is no functional speed gain by adding memory. Only if you get to the point where constant swapping is bringing the system down, i.e. when opening lots of programs and opening plenty content rich windows, some RAM will help to avoid that.

Adding 2 x 512 MB RAM in addition to my 128MB bar and removing these shows no side effects during my tests. No menu, no window, no butten reacts smoother, snappier or quicker, no file copy process, no application start and no system boot time gets any measurable speed boost.

The speed hits are in general not memory related and therefore cannot be cured by adding insane amounts of it. Do not mismatch a sluggish system with an overloaded swapping system! The latter can be helped by adding RAM, the former can be helped by skilfull programmers.</STRONG>

There are instances when more RAM helps. You're right that menus, window resizing, etc are generally not going to be helped by more RAM assuming you have a reasonable amount to start with. Where I have noticed a difference is when switching between/launching applications while having multiple applications already running. The way I work, I tend to have several apps running at a time and some of them are memory hogs. I started with 192 Meg and added another 256 Meg.

I used to dread having to run a classic app because it meant starting classic up. Now I just leave it running with no noticeable penalty.

[Colonel Panick]

Linux runs faster than Mac OS X because Mac OS X has a heavy GUI weighing it down, Aqua.

1) You mean Quartz not Aqua. I don't think OSX problem is water retention.

foobars, I believe ndptal85 really meant aqua. Aqua has got all kinds of processor-intensive (quartz-intensive, if you like) graphical effects which slow the whole thing down. El presidente stated in his article that quartz already got quite up to speed...

As for El presidente, concerning your article, I have a little question:

OS X chews up RAM like there's no tomorrow; part of the reason for this is that every window on screen has a backing store, so creating a new window means allocating a good bit of memory.

Does this also count for invisible and docked windows? Do I really have to close windows to free up memory?


(P.S. Typing the previous question, makes me wonder, from a user-interface point of view: why is there a disitinction between docked and invisible windows in the first place? I believe docking windows from invisible apps would avoid a lot of confusion.)

I have spoen with a friend who is an Apple employee and he said that Apple wants to get all the hardware bugs out of the way first. Second will be software features and optimization.

Remember, time takes time.

Petrie

[BuonRotto]

You're friend is right. That's not an arbitrary decision either. The second and third phases require the first to be resolved. No getting around that, unless you want to waste a lot of time, money and energy redoing your work.