Reported slowness due in variable expansion
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 32/100
- Issue 类型
- 缺陷
- 描述清晰度
- 需要澄清
- 活跃度
- 停滞
- 技术栈
- python
- 领域
- devtools, performance
调研方向
该 issue 没有指明文件、测试或可复现案例。首先跟踪 debugpy 如何处理超大值的变量呈现和展开，然后将其行为与此处描述的 DAP lazy 和 indexedVariables 机制进行比较。当大型变量不再阻塞调试器交互或使客户端不堪重负时，即表示完成。
由索引模型根据 Issue 内容生成。
描述
Isidor pointed out a tweet that mentions
S Code’s debugger would lock up whenever I stepped past a line like: S=tensor.untyped_storage()... the debugger window that automatically displays local variables started a dump of over a billion elements from the debug server before it would process any other commands.
I have not attempted to repro myself, but there are a few ways in the debug protocol that cases like this can be handled:
- Set
lazy: trueon theVariablePresentationHints of potentially expensive variables so that they aren't expanded without user action - Use
indexedVariablesto allow the client to request a small number of a variable's contained data and page through it
Even if it's unavoidable that a giant variable's data is loaded into the debug adapter, it should use these mechanisms to avoid overloading clients and slowing down interaction on the protocol.
Let me know if there's anything I can help with from the VS Code side :)
- 主要语言
- Python
- 星标
- 2.5k
- 派生
- 202
- 平均合并
- 5 天 1 小时
- 30 天内合并 PR
- 1
贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
microsoft/debugpy 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 78/100
-
documentation
难度 2/5 1-3 小时 新手友好度 68/100
-
难度 2/5 1-3 小时 新手友好度 78/100
-
documentation
难度 2/5 1-3 小时 新手友好度 62/100
-
难度 3/5 1-2 天 新手友好度 68/100
查看 microsoft/debugpy 的全部 Issue
相似的 Issue
-
bug
难度 2/5 1-3 小时 新手友好度 75/100
stephrobert/dsoxlab#238 ·
-
难度 2/5 1-3 小时 新手友好度 75/100
-
难度 2/5 1-3 小时 新手友好度 75/100
sublimehq/package_control#1780 ·
-
难度 2/5 1-3 小时 新手友好度 65/100
-
难度 2/5 1-3 小时 新手友好度 70/100
nwg-piotr/nwg-displays#145 ·