Denken Sie über eine einzelne Probe, des Stapels für alle Threads gleichzeitig.
Was Sie wissen müssen, ist - wer für wen wartet, und warum. Normalerweise, wenn Funktion A über B auf einem Stapel ist, bedeutet dies, dass A darauf wartet, dass B zurückkehrt, und der Grund ist, dass A B etwas tun wollte. Wenn Sie sich einen ganzen Stapel, für einen Thread, ansehen, erhalten Sie eine Kette von Gründen, warum diese bestimmte Nanosekunde ausgegeben wird. Wenn Sie nach Geschwindigkeit suchen, suchen Sie nach Ketten von Gründen, die Sie insgesamt nicht brauchen (weil es eine schwache Verbindung gibt). Dies funktioniert auch, wenn die Kette in I/O endet. Wenn es Benutzereingabe ist, wartet es einfach auf den Benutzer. Aber wenn es ausgegeben wird, oder Festplatten-I/O, oder einfach alte CPU-Ankurbelung, könnten Sie etwas tun, um es zu reduzieren, und eine Leistungssteigerung erhalten (wenn Sie das gleiche Problem bei 2 oder mehr Samples sehen).
Was passiert, wenn Thread A ist für Thread B warten? Dann, was Sie am unteren Ende von A's Stack sehen, ist eine Funktion, die auf den anderen Thread wartet. Sie benötigen, um herauszufinden, welcher Thread B ist, und schauen Sie sich seine Stapel, denn je länger es dauert, desto länger dauert A. Das ist also schwieriger, aber davor haben Sie keine Angst.
Ich spreche über manuelle Profilierung hier, wo Sie Proben nehmen, um sich in einem Debugger, und wenden Sie Ihre volle Aufmerksamkeit auf jede Probe. Profiling-Tools neigen dazu anzunehmen, dass du faul bist und nur Zahlen willst. Wenn nichts aus diesen Zahlen springt, wirst du glücklich sein, weil du nichts gefunden hast. In der Tat, wenn einige dumme unnötige Aktivität wird 30% der Zeit zu nehmen, dann im Durchschnitt die Anzahl der Proben erfordern Sie es zweimal zu sehen ist 2/0,3 = 6,67 Proben (keine große Zahl), und es ist sehr wahrscheinlich, dass Sie werde es sehen und the profiler will not. Das ist random pausing.