Converting "language" to an enum ("language: %d message %s"), and converting "size" so that it was just "%zu" instead of "size: %zu" thinking it may be faster to parse did not seem to improve my life dramatically except for making my code a little harder to read.
47211696 [custom instruments] defaults for <enum> Elements
47211508 [custom instruments] <enum> as a top level declaration
while going through the exercise of using enumerations.
Is os-signpost-interval-schema recording backtraces even though I don't care about backtraces? I don't have a backtrace column anywhere...
Also, backtrace recording is not implemented at this time. It's turned on at the logging handle level, and by default log handles do not record them.
Since you're on a Mac, run "log stats" from the command line. If you want to be pro, you can use "log collect" to create an archive of the window of time you were seeing the problem, then run "log stats --archive path" to narrow it down. When it finishes, it will give you a break down of who is filling up the logs. Logging is a shared resource on the system, so the overload doesn't have to be caused by your app.
In live mode, data is sent directly to an Instruments recording service, so if the recording service backs up, the data gets dropped rather than blocking the sender. In Windowed Mode, logging signposts goes into something like a circular memory buffer, so it's very hard to overload. The downside is that the older data is evicted from memory quicker. If the problem you're seeing is still happening in Windowed Mode, then something isn't functioning as it was designed. That's not good.
With regards to live mode, choosing a target rather than All Processes can help, and not including instruments with wide open filters like "os_signpost" and "os_log" will also help. Since I see the "custom instruments" tag, I'm assuming you've supplied a subsystem and category and are using your own custom instruments, so the filtering you get with that should help with the data loss.
Oh, and finally, having "Console.app" open does change the equation a bit, so I'd recommend quitting that app before recording.
Sorry I wasn't completely clear...
I am recording off of an iPhone (SE) to my Mac via USB. Not sure if that makes any difference.
I am focusing on a single app, and the only instrument that I am recording is my own.
Console.app is not open.
As far as I know there is no equivalent to "log collect" to pick up data from my phone... happy to be educated of course
So it does appear windowed mode is working okay (contrary to what I said previously)/ I set the window for "20 seconds" and it doesn't appear to overflow. This seems odd to me though given that my run is usually about 8 seconds. Why does windowed mode work for 20 seconds, but live or deferred mode does not?
And how fast is "too fast" in general and how many is too many? I see in the recording preferences that there is a DTrace buffer control. Does this buffer work for ktrace as well?
My custom instrument is pretty useless if I can't sort this out.
DTrace doesn't exist on iOS. Ktrace buffers are sized based on a heuristic. Both of these technologies can be overrun if Instruments can't drain the data quickly enough, in both live and deferred modes.
I've been able to comfortably record thousands of messages per second on a Mac in live mode, but the performance impact is measurable in a time profile. iOS's capacity to record varies greatly between devices, but I'd expect hundreds per second to be achievable. The other problem you might be seeing is that if your app has taken so many system resources that Instruments can't get enough time and memory to move the data off the device, then that could manifest the same way.
Live and deferred modes requires every signpost to be forwarded to Instruments. This bypasses all the optimizations made by the system in order to display the data immediately. It's true, deferred mode can batch the data, but it does imply lossless recording when possible, so it uses the same machinery as live mode. Under heavy loads, it can still be overrun.
In Windowed mode, however, Instruments steps out of the way and lets the OS record signposts into its circular buffer, making it theoretically impossible to overload it under normal use. Windowed mode is used for dense recordings where a long trace is impractical to even analyze by the user (i.e. too much hay to find your needle).