Mac OS X Leopard - ARCAism

478
CHAPTER 25 MAC OS X DEVELOPMENT: THE TOOLS
Property List Editor
Property lists, known colloquially as plists, are files originally designed for storing properties,
which is to say, preferences. When you set the preferences of a program in its preference panel,
or via the command line’s defaults command, you’re editing that application’s property list.
However, with the introduction of the XML plist format, these have become a handy way to
store standard data structures, such as arrays and dictionaries, in an external, human-readable
format. The Property List Editor is a convenient, schema-aware way to create and edit plists. It’s
also the only way to make heads or tails out of the older, but still useful, binary plist format.
Shark
Every developer wants their application to be fast, but the biggest mistake a programmer can
make is writing their code for speed. Fast code is optimized code, and the lower a language is, the
more opportunity for optimization there will be. Java offers few chances for optimization compared
to C, and C is a snail compared to assembly language.
As fast as they might be, low-level languages are harder to read and take much longer to
write. Even if you don’t change languages, it’s a shame to pick a library or function based on it
being faster instead of it being easier. Worse than all of that, all those optimizations that took
forever to do will probably end up making the program slower.
Why? Because humans are surprisingly bad at guessing where performance bottlenecks are.
The only way to know for sure is by using a specialized sampling tool. This tool will watch the
application and figure out what it’s doing and for how long. Shark (shown in Figure 25-28),
which comes with the free developer tools, is one of the best optimization programs available.
Figure 25-28. Bare Bones’s blazing fast BBEdit profiled by Shark
Avoiding blind optimizations makes the development cycle faster, because it lets programmers
choose code based on ease of writing and readability. That leaves plenty of time for
profiling with Shark, and then pinpointing bottlenecks and performing optimizations only where
they will make the biggest difference.
Hard rules are anathema to programmers, but here’s one even the most stubborn of hackers
should follow: never, ever do something “because it’s faster,” until you run Shark.