MacHack slides and hack
Some people might find the slides from my MacHack talk useful, so I’ve posted them for your viewing pleasure. For the sadists out there, I’ve also uploaded a copy of my hack, Boot9. Here they are:
- Application Performance on Mac OS X (PDF, 263K): Slides from my talk on how developers can improve the performance of their applications on Mac OS X.
- Boot9 (.tgz, 396K): A replacement for SystemStarter, the Mac OS X startup items, and SystemStarter’s graphical code that makes the Mac OS X boot process look like Mac OS 9.
Buzz Andersen Said,
June 30, 2003 @ 12:16 pm
Great stuff–thanks for posting that! Performance has become a real interest of mine lately. I’m actually rewriting my iPod DB parser to try to squeeze out better performance, and I’ve been generally aware of a lot of these principles (avoiding excessive dynamic memory allocation, etc.), but not to the extent that you illuminate them. Much appreciated!
Bo Said,
July 3, 2003 @ 3:18 pm
Just one question. What’s the deal with alloca()? I’ve read in a few places now warning not to use it unless absolutely necessary, but it seems to fit such a convenient niche that I can’t help myself.
Also, I was reading the gcc manual and noticed that it had an extension to the C standard that allowed you to dynamically set the size of an array just by putting a variable expression inside the brackets when you declare it. (found at file:///Developer/Documentation/DeveloperTools/gcc3/gcc/Variable-Length.html). This seems like it would handle practically every situation that I’d be tempted to use alloca in, but as a gcc-only extension, I’m worried to embrace that as an alternative.
Or am I thinking about this too much and should just be using malloc()/free()?
Brian Palmer Said,
July 5, 2003 @ 4:11 am
Bo, while I’m not sure exactly what issue Eric’s thinking of with alloca(), the C99 standard (i.e., the new version of C, which in a few years with luck will be the default C everyone uses) has the idea of variable-length arrays that shares some features with the gnu extensions. I believe gcc is moving towards these vlas, but I’m not sure of their progress, or what issues they’ve run into.
One of the things I remember people pointing out with alloca() is it’s yet another complication on memory management. Pointers to this memory shouldn’t be handed out any more than pointers to local (stack) variables should be, but it’s a trap people fall into. Furthermore, since this is likely to be pointer to what will soon again be valid memory where, for example, return addresses are stored, a very straightforward security violation can result.
Eric Said,
July 5, 2003 @ 5:33 pm
The biggest issue with alloca is that very few implementations return failure when the allocation in question would overrun the stack. I can’t speak for everyone, but I strongly dislike using APIs whose failure can’t be checked or can only be determined by seeing that my application just crashed.
As far as I know, Windows correctly returns NULL when there’s insufficient stack space for alloca to return successfully, but Solaris and Mac OS X don’t.
I don’t know what the failure case is for variable-length arrays. Since I can’t see how they could communicate failure, I’d be hesitant to use them.
Bo Said,
July 5, 2003 @ 5:59 pm
Ouch. Yeah, I can see how that’s a bit of a problem. The funny part is how assiduous I’ve been about checking if alloca()’ed memory is nil, never suspecting that my compiler was conspiring against me. Well, back to malloc() for me.