Performance issue when stepping through a deep callstack
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 30/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Đình trệ
- Lĩnh vực
- devtools, performance
Hướng nghiên cứu
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.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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)
- Ngôn ngữ chính
- Ruby
- Star
- 1.3k
- Fork
- 146
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của ruby/debug
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 68/100
-
Support exceptionOptions in setExceptionBreakpoints to catch arbitrary exception classes via DAP Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 55/100
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 45/100
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 52/100
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
palladius/rails8-app-on-gcp#145 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
rubocop/rubocop-rspec#2236 ·
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
riscv/riscv-unified-db#2624 · 1 reaction ·
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100