So, Does anyone know THE difference between 10 and 10.1 ?

[Sarc]

Just wondering, does anyone know what's the main under-the-hood change between OS X 10.0.x and 10.1 that makes the latter one gain such noticeable speed ?

[Guy Incognito]

They had a bit of code that read something like SpeedupOSX and it was accidently set to 'false' in 10.0. Some clever guy decided it should be set to 'true'.

[Sarc]

No, really, I heard that it was like a Framework-level change, something like dynamic library loading or something like that. Dunno really.

[MacGorilla]

They also removed the code SnailSpeedInTheUI ;)

There were many, many changes that boosted the speed. Check with Apple for a complete list.

[juanvaldes]

Basically a lot of code clean up all over the system. There is no single change that speed everything up.

[brachiator]

They removed all the debugging code to make it snappier... :D

[MacGorilla]

Originally posted by brachiator:
<STRONG>They removed all the debugging code to make it snappier... :D</STRONG>

You just couldn't help it, could you?? ;)

[Millennium]

As others here have mentioned, there is likely no single under-the-hood change which caused the speed jump.

I know the "removing the debugging code" theory is constantly mocked (I know this only too well), but I don't think it should be completely discounted. Even in the current release of 10.1.1, there are several things which are known to still be in the debugging process. Some, like window buffer compression, are off by default. Others, however, are not. It is true that removing debugging code will not have a major effect on speed, unless the code was in a critical area that gets executed many times a second. But it can still have small effects in certain areas. Even large ones, if the code is in the right place. Just compare the debug versus optimized buildsof Mozilla for proof of that.

Related to the debugging-code issue is optimization. Compilers these days are good, but even so, there's still nothing that can quite match a person skilled in assembler. Sometimes, all it takes is a minor-seeming tweak to have a massive speed boost. Again, that all depends on where the code is. Shaving a single instruction off of a function won't do much for rarely-used code, but against something that run millions of times per minute, the time saved can add up very quickly. The best examples I can think of on OSX would be QuickTime and Quartz. Even small optimizations can have a domino effect, and cascade into large time savings. It just depends on the placement. Of course, you can only optimize something so much; eventually, you'll hit a bare minimum number and/or type of instructions, and you won't be able to go beyond that. But you'd be surprised at just how good you can get.

And just how is that related to debugging-code removal? Actually, that one's simple to point out. Optimized code tends to be harder to debug. Just as in real life, when you streamline something, you often have to do it in non-obvious ways. They work well, but they're harder for a third party to understand. They can't pick up and improve on what they don't understand, of course. The same is true of computers and people. It's usually harder to understand what optimized code is really doing. How many C programmers here, for example actually understand what a Duff's Device does, and why it is faster than "traditional" loops? Very few, I'd wager. Even I still get tripped up by it sometimes. And yet, people still use it, because it is faster.

Most of 10.1's improvements were probably done via optimization. Debugging-code removal likely plays only a minimal role. Most likely, the biggest changes were in Quartz, which is much improved even though it still has a long way to go.

[kongtomorrow]

Well, there was the switch to the 2-level namespace, is that what you're thinking of?

If I knew more exactly what that means or whether that helped speed things up I'd tell you.

[johnnylundy]

Originally posted by Sarc:
<STRONG>Just wondering, does anyone know what's the main under-the-hood change between OS X 10.0.x and 10.1 that makes the latter one gain such noticeable speed ?</STRONG>

In the Finder, the reason window resizing is faster than IE is partly due to a kludge where they map out the extent of resize as soon as you press on the resize button. You can feel this slight delay.

In the Dev Tools is a Quartz Debug app that lets you see all the un-optimized and non-hardware-accelerated screen redraws, and you can see the mapping that the Finder does mentioned above. It may cause seizures so be careful. :cool: :cool: :p

[Sarc]

Thx people, I now have a somwhat clearer vision of 10.1 vs. 10.0.x .

Cheers