I went to an Apple seminar (basically an advertisement for WWDC. I wish.) this evening. I'd been to one of these two years ago, and for the most part this one just repeated the same lines as the last: "We're all about open standards. OS X is way cool. We like Open Source. Cocoa is way cool." This one was, however, lacking the disgruntled OpenDoc programmer in the audience looking to take Apple to task for its habit of abandoning technology that isn't quite working out for it.
Two things were interesting this year, though.
The first was the showcase of the profiling tools that come with OS X 10.3. The guy whose name I've sadly forgotten gave an impressive demo of Shark, the profiling tool. I suspect a certain amount of configuration happened behind the scenes, but essentially the demo consisted of:
- Start Shark
- Run application
- Stop Shark
- Look at statistics
While running, Shark would use instrumentation built into the OS and the hardware to profile all the running applications. After stopping Shark, you get an overview of which applications were taking up the bulk of the CPU time during the run. Drilling down to individual applications, you got:
- An overview of which functions were using the most time
- For those functions were source is available, a source listing colour coded by which lines of code were particular "hotspots"
- Annotations on both of the above views providing clues as to why they might be slow
- Suggestions on what might solve the problem (using an alternative function, unrolling loops, etc)
It's hard to impart just how impressive the demo was to someone who can only associate profiling tools with the phrase "wrestling with". It was the code-view that surprised me. The simple double-click down to something that the programmer can really identify with.
Of course, the demo was carefully staged so that the application in question was doing something time-intensive that could be made significantly faster by using a more efficient sqrt() routine or enabling Altivec extensions. However, the fact remains that this tool comes included with the OS, whereas every similar tool I've seen for Java is either (a) clumsy, slow and annoying, (b) expensive or most frequently © both.
Keep in mind this thing was profiling C code. Java runs in this carefully managed environment, surely we should have better tools? I suspect that if the Java vendors don't wake up, this is somewhere .NET can really clean up by making similar tools just come with the environment.
The other cool thing that was demo'd was Xgrid, the OS X grid computing framework. In typical Apple fashion, they took a complicated subject (grid computing), and reduced it down to "Here's ten lines of code. I compile it like this, then I tell the GUI to run it across whatever other machines it can find over Rendezvous." And it Just Worked.
