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.