mikeash
commented
6 years ago Sorry, I didn't see this for a while.
Finding performance problems with a snapshot like this is going to be tricky, since you only capture a single moment in time. It should be possible to get some useful information, though, assuming that it's likely to be in the middle of whatever is taking a lot of time when you trigger the stack trace. You'd have to look at every thread and see if any of them is doing something costly. In your first image, for example, the fact that thread 0 is in cellForRowAtIndexPath indicates that might be a hot function. (I assume you inserted a sleep just to make it look slow.)
Any symbolication solution that works on crash reports should also work on these not-quite-crash reports. They still look just like crash reports.
Feel free to e-mail me directly rather than continuing here, mike@mikeash.com
Man, sorry for asking here since I cannot ask issue from the page of PLC; I'm using your popular repository: https://github.com/plausiblelabs/plcrashreporter
What I'm doing now is monitor cpu/gpu/memory programmatically(not monitoring crash, since there already many 3rd party lib can do that, what I'm monitoring is app's performance);
For example, when cpu overloads, I'll dump the backtrace of the suspicious thread with BSBacktraceLogger ,also I use your PLC to catch the whole trace info.
What I get is like this, by PLC:
And by BSBacktraceLogger:
But seems none of above stack trace can help me to analyze and find how the performance issue happens.
Generally, when we are using 3rd party "crash report" platform, we can see crash log like following, with clear line number, method, etc, which can help very much in specifying and locating issue (I know it's symboled by atos):
But now my app is not crashing, just memory overloads, no crash log; I just want to locate where or which thread or what action that caused the occasional low performance; Am I wrong? or How can I better analyze the stack trace? Man