Shouldn't OS's get faster?
Processor speeds are increasing (well, not that much) but the Mac's OS is not. I know new features and splashy graphical interfaces don't help the speed of OSX, but I wish there could be a compromise.
I also realize there's an adjustment period where OSX is slowly being optimized. I just hope some day soon, it'll be faster than OS9.x or even 8.6.
BTW, this applies to all new OS's in general.
I also realize there's an adjustment period where OSX is slowly being optimized. I just hope some day soon, it'll be faster than OS9.x or even 8.6.
BTW, this applies to all new OS's in general.
Comments
*no 68k code
*pre-emptive multitasking (GUI should be more responsive)
*there must be more reasons?
Now, I've only used it on my iBook 500, but it sucks. It becomes unusable sometimes. I almost never use it. No reason to: 9.2.2 is rock solid for me, and I have extensions out to the wazoo (I also configure the sets out to the wazoo, the first thing Mac owners can do to make 9 stable)
Last time I asked why OS X was slow, I think everyone just ignored me or said I didn't know what I was talking about. But if anyone has enough technical knowledge to clearly explain why OS X is so slow, I'd be greatful, and lots of other people would too, I'm sure! After all, it can't still be all that debugging code!
In fact... get this... even when compiling multiple apps in the background, and my CPU is maxxed out at 100% use, the feel of linux is still snappy. I can still listen to my mp3s w/ out missing a beat of that lovely progressive house (Proton radio). Web browsing, while slowed, is acceptable.
OSX, over time, will hopefully get to this level. It is possible.
M$ get slower and slower because of constant adding of 'features' wherein they try to come up with reasons for windows users to upgrade to the latest version. It makes a pretty bloated OS.
Most Linux apps aren't pervasively threaded.
Threading can be good, but too much of it can also be bad. It's one of the reasons why the BeOS never really got any large apps, for instance the Nuendo dev had to do all sorts of tricks to trick the OS in order to be able to use a single thread.
All this said, some parts of the OS do indeed need better threading.
<strong>M$ get slower and slower because of constant adding of 'features' wherein they try to come up with reasons for windows users to upgrade to the latest version. It makes a pretty bloated OS.</strong><hr></blockquote>
Not to start a flame, but at least some of that may be offset by their increased MHz.
Unfortunately, Motorola hasn't moved along as quickly to keep up with the requirements of OSX.
I really hope it is possible to have an incredibly quick and responsive OSX, say by this time next year.
On new hardware OS X is fine, and it's the current hardware that Apple probably predicted would be out when OS X was first released.
Anyways, OS X optimization will continue for years. 10.2 will boost performance considerably and probably will make OS X acceptable in terms of speed for most supported hardware (within reason).
If one rumor I know of is true, then 10.2 will introduce a new version of Quartz that is fully accelerated by video cards (All Nvidia cards, and every ATI card since the Radeon). If so, then Aqua speed will no longer be an issue...although there may still be problems with file system speed...list view, anyone?
On my G4 400 MHz system, 576 MB RAM, OS X speed is ok, never unusable, and sometimes quite responsive. I'm looking forward to 10.2, but I don't think about speed or lack thereof very often.
Except that I find that using graphics apps that require intensive video updating [Illustrator, PS to a lesser extent, InDesign] OSX can become unuseable on a DP1GHZ machine. How much of it is display issues vs. crappy carbon ports I don't know, but OS performance and app performance are inseperable--i.e. an OS ain't worth sh*t if its crucial apps suck. And if you don't buy that argument then ask yourself why people prefer Macs for apps like PS and Illustrator.
Hint: It ain't cause Macs are cheaper and faster.
[ 04-18-2002: Message edited by: cowerd ]</p>
<strong>
If one rumor I know of is true, then 10.2 will introduce a new version of Quartz that is fully accelerated by video cards (All Nvidia cards, and every ATI card since the Radeon). If so, then Aqua speed will no longer be an issue...
</strong><hr></blockquote>
I hope that is true.
From the article:
[quote]The culprit, it turns out, isn't the new iMac's hardware, but its operating system, which Apple focused on getting to market first and bringing up to speed later. In order to let OS X support as many existing software applications as possible, "Apple supported a number of legacy technologies designed to ease their transition to the new operating system," said Nathalie Welch, the company's public relations manager for hardware.
As a result, Welch said, "We are merely at the beginning of the performance opportunities in Mac OS X."
Jason Hazlett, a Mac developer for Opera, said performance problems are something application developers have to live with at this stage. "To get any application running on OS X is one thing, but getting it to run well is another," he said. "The most important thing to do is to use the OS X native event model. I cannot speak for Internet Explorer, but the Opera beta you are running does not (run the event model). This goes a long way in explaining what you are observing."
Hazlett said that early test versions of Opera's future 6.0 release, which uses OS X native events, are already faster than their predecessors on MacOS 9.2, the previous generation Macintosh operating system still booted by skeptics and late adopters.
Jimmy Grewal, Microsoft's program manager for the Mac version of Internet Explorer, agreed that the problem lies with OS X, not the browser. In particular, he said hardware graphics acceleration was largely missing from OS X at this stage in its development. "The effort of drawing something to the screen (on Windows) can be offloaded to a graphics card, but in OS X the CPU is heavily involved," he said.
Grewal defended Apple's strategy of releasing a slow version of OS X now rather than a faster one later. "That was a conscious decision Apple made," he said. "They optimized for user experience rather than raw performance."
The goal, he said, was to update the Mac's look and feel to the new Aqua interface, while avoiding onscreen glitches and user interface inconsistencies that a hasty excursion into hardware acceleration might have brought. "We think our users wouldn't trade that performance difference for the experience," he said.
<hr></blockquote>
SETI takes about 10-11 hours.
On my 700 MHZ G4 OS X iMac, SETI takes about 11-12 hours. I do get an occasional spinning beachball, but I've never had to wait 4 minutes while an application I've tried to bring forward redraws. It makes multitasking on Win2000 nearly impossible.
<strong>I don't know what an event model is, Amorph</strong><hr></blockquote>
Events are messages that allow different bits of code to talk to each other - most importantly, in this instance, they are the primary way that the OS talks to applications, and applications talk to the OS. They're most often used to handle anything that doesn't happen in a predetermined order, or at a predetermined time - for example, neither an application nor the operating system has any way of knowing when the user will decide to print something, so Print Document is an event. Events can be broadcast, as well: When you Shut Down, Mac OS sends Quit events to all running applications.
An event model is a particular design (and implementation) for sending and receiving events. The Apple Event model is one, carried over from classic Mac OS. BSD has its own, and there are also Carbon events and Cocoa messages (which are similar to events).
As you can imagine, in a GUI, events are flying around at a dizzying rate. Every application in a GUI environment has an "event loop," which is a bit of code that does nothing but sit there and wait for something to happen (via an event). An event is posted every time you press a key, every time a field or window gains or loses focus, every time the mouse is clicked, double-clicked, clicked-and-held, etc., and in some windows, every time it's moved (so that the simple act of using a mouse in a game to steer your character around can generate hundreds of events very quickly). Window openings, closings, drags and resizes generate events. Every time a file is moved or duplicated or deleted, or an alias is made, several events fire off - at least one from Finder to the OS saying to actually perform the action on the file, and then one event to Finder - which is then broadcast to all of Finder's open windows - to update their contents to reflect the change. So, obviously, the efficiency of an event model and the efficiency with which it's used are absolutely crucial to the performance of a modern OS.
Carbon supports two event models: The old way, and Carbon Events. The old way requires every application to handle all events (Open, Close, Print, Quit, etc.), and it polls the OS periodically to check for any new events, bogging things down - sort of like setting your email client to check your email 100 times a second would bog things down.
There's more to it than that, but that's as much as I feel like typing right now. Hope this helps.
[edits for clarity and grammar]
[ 04-19-2002: Message edited by: Amorph ]</p>
---
MacOS X 10.1.4
Anyone who has actually used the piece of shit that is the Win9x line and Win2k/XP can tell you that.
Today the same is true with OS X, right now there is a lot of code that needs to be updated and or optimized and once it is things will get faster. Some of this will be from just general cleanup that happens as the OS is updated and others will come from better compliers (gcc3 anyone?).
Daniel
At least I could run 68K code without having to launch Classic. At $150+ per upgrade for major apps, and 8-month to 1 year cycles, we've got a long wait, and more $$$ to spend before anything gets "optimized" for OSX.
[ 04-21-2002: Message edited by: cowerd ]</p>
micro$oft are experts at this.....
<strong>Ah, thanks Amorph and AirSluf, very informative replies! And I was just going to convert to AppleWorks, Amorph!
I haven't heard anything about the latest upgrade, but Apple's been working on that. AW 6.0.4 polled the OS 8,000 times per second. AW 6.2 dropped that to about 2,500. One hopes that it will stop polling altogether, but since AW is written with its very own, highly idiosyncratic class library, moving it over to OS X-native Carbon without breaking OS 9 support will take some doing.
That notwithstanding, it's a decent app. It works well for me. 6.2 was a big step forward.
I can't comment on Office X - I've never seen it. I've heard that it's slow.
[quote]<strong>So are the majority of applications still CFM and not Mach-O, and this is what is behind some of the rainbow cursor effect?</strong><hr></blockquote>
I'm not sure what the CFM/Mach-O ratio is, and I'm not sure of the extent to which that would effect whether or how often the rainbow cursor comes up.
[quote]<strong>"Chess" is the most NEFARIOUS app I have seen.</strong><hr></blockquote>
That's odd. It's an old NeXTStep app (Cocoa on top of UNIX code). Its problems have nothing to do with CFM or Carbon.
[quote]<strong>This thing will monopolize my CPU for minutes, perhaps longer since I always force quit it, and this is on a 500mhz iBook, which should be nothing to sneeze at. The Dock, nothing will respond.</strong><hr></blockquote>
I'm pretty sure something of yours is hosed up, in that case. I fired up Chess and got my butt kicked for a while, and on my machine (450MHz G4) I didn't notice any decline in responsiveness. Even when I've had applications get tied up with the color wheel (Canvas 8, Finder) I can still switch to something else more or less instantly.
I'm not sure what your problem is, but it sounds like you have one. Chess should not be able to monopolize your system.