Getting Chronoscope to work on Mac OS X has high priority, but is not an easy task. The runtime architectures of Mac OS 9 and Mac OS X are very different. Mac OS 9 is anachronistic, in its cooperative scheduling (at the user task level) and lack of SMP. However, this environment allows profiling tools like Chronoscope to have full information about the behaviour of an application; if we assume cooperative multitasking, and cooperative threading, then a profiler can instrument every OS call and thread switch, and know exactly what code is running on the (assumed) single CPU at any one time. It then makes sense to draw a timeline view of the execution of the program, as Chronoscope does. All time can be accounted for. Interrupt-time code does throw a small spanner into the works, but at least we can be sure that they run to completion.
On Mac OS X, things are very different. The kernel schedules processes preemptively (which means that a process can be pulled off the CPU at any time, without any kind of notification, and then scheduled again later, possibly on another CPU). Within a single process, multiple threads may be running, and themselves be preemptively scheduled. If the machine has more than one CPU, several such threads can be running at the same time. In addition, some of the Carbon "interrupt-time" callbacks that we knew ran to completion under Mac OS 9 do not do so under Mac OS X; they are emulated using threads, and so can be interrupted by the main thread (or even run at the same time as the main thread on a different CPU).
So, even if I were to port the Chronoscope engine to Mac OS X, the data it produced would not be a full picture of application behaviour. To get that, I'd need to get kernel scheduling notifications, which isn't trivial. If you can think of a way to address this issue, please let me know.
Yes, I think there is a 2Gig limit, since I don't use any of the fancy file system APIs for large files. Not that you'd want to produce a larger data file than this (see the next FAQ item).
The viewer is currently limited to loading files that fit entirely in memory. Yes, this sucks, but then so do the file mapping APIs on Mac OS 9. It wouldn't be too hard to write some code that uses a backing store for the in-memory data, but it would hurt viewer performance quite a bit. Go and buy more memory, or crank up your VM size, and be prepared for some swapping.
The viewer outputs big print jobs, if you are not careful. It tries to print function names on the output, and can output some very dense forests of lines. To make things easier, zoom into the view. Adding UI to configure the print output is on the to-do list.
Yeah, I worked hard to keep the viewer responsive almost all the time, even with large data sets. The data is sucked in using async file I/O, with concurrent data processing. All UI timeline drawing, and statistics data collection happen on idle callbacks (PowerPlant LPeriodicals). There are a few sucky non-yielding chunks of code (e.g. when clicking on a root function call in the timeline), but I'm trying to eliminate them.