Performance issue when stepping through a deep callstack
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 30/100
- Issue-Typ
- Bug
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Veraltet
- Bereich
- devtools, performance
Rechercherichtung
Start at ext/debug/debug.c lines 92-98 and inspect how rb_make_backtrace is used while stepping through a deep callstack. Compare the proposed rb_threadptr_backtrace_object and debase approaches, including their *_core.h requirements. Done means stepping through roughly 150 calls no longer incurs the reported slowdown and memory pressure.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Your environment
ruby -v: 2.7.2p137rdbg -v: 1.6.2
Describe the bug
When stepping through with a deep callstack, the debugger becomes slower with each step.
To Reproduce
In a codebase which has a method that's ~150 calls deep in the stack, add a breakpoint, debug, and step through.
Expected behavior
It wouldn't be slow
Additional context
We are facing this issue at Stripe, and we tracked down the problem to: https://github.com/ruby/debug/blob/296daa6742e114395a4ce336b8721d48a6e5e52f/ext/debug/debug.c#L92-L98
This seems to be generating the full backtrace through rb_make_backtrace, just to then take the size. rb_make_backtrace (source) generates an array of strings each time it's called. Those strings end up not being used, and after a couple of iterations, you end up with a big memory footprint, which causes the GC to collect them, significantly slowing down the debugger.
Luckily, it looks like you are already aware that this is inefficient (given the // TODO: more efficient API) :)
Looking into alternatives, I came up with a couple of options (but open to any other ideas):
- Use
rb_threadptr_backtrace_objectto skip the formatting of the backtrace, saving some extra memory (but still generating more than necessary) debasesolves this with a different approach: https://github.com/ruby-debug/debase/blob/5780803819f16190ce50ddfdad5775acf8f95fd1/ext/hacks.h#L26
Both of them, though, require the inclusion of *_core.h, which is not currently possible (debase solves it by using its own version of ruby_core_source)
- Vorherrschende Sprache
- Ruby
- Sterne
- 1.3k
- Forks
- 146
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Beitragsleitfaden
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus ruby/debug
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 68/100
-
Support exceptionOptions in setExceptionBreakpoints to catch arbitrary exception classes via DAP Offen
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 55/100
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 45/100
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 52/100
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 35/100
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
palladius/rails8-app-on-gcp#145 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
rubocop/rubocop-rspec#2236 ·
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
riscv/riscv-unified-db#2624 · 1 Reaktion ·
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 88/100