Closed timcharper closed 8 months ago
addresses #45
In draft mode for now as we will also want to update the README. And I need to jump through the FSF hoops.
@svaante wdyt ?
ah, with https://github.com/svaante/dape/commit/e84de3dad6f6071fc83d2b220a76888d0e18d6c6, probably don't need the json rpc checker.
updated PR to remove dape-doctor json-rpc version checking... I like the approach you have better anyways
Not a bad idea, I seam to remember lsp-mode has something similar. I wonder if there is any precedence in some built in package to copy implementation details.
I am not sure I like the magic numbers; I would like the rationale of those specific values documented
Yeah, from what I understand, the max value is 1MB on linux, 64kb on Mac OS, and no limit on Windows?
I'll add some docs.
I decided to benchmark the differences as best I could. My method was to set a breakpoint in a specific module of code in a large project, and time the difference between dape--update-state starting and dape--update-state stopped (when the breakpoint was hit).
There's lots of variables aside from debugging that could affect the speed, so this was not a super thorough test. But in my experiments, I saw about a 10-20% speedup using
(setq read-process-output-max (* 1024 1024)) ;; 1mb
(setq gc-cons-threshold 100000000) ;; 100mb
vs the defaults (4096, 800000), respectively.
I'm not sure a dape-doctor command is warranted since I don't think we're looking at orders of magnitude improvements here. Bottlenecks are likely elsewhere (debug JS process hits 100%, for example).
There's probably more advanced profiling that can be done, but personally, I'm satisfied with the performance appearing to be slightly better and not being worse.
I'm going to remove dape-doctor from this PR and just add a note in the README.
Nice work @timcharper I have not investigated "startup" time at all, but rather update rate i.e. dape-next and all info buffers populated. Where I have found emacs screen redraw as the botelneck (maybe an osx issue).
Have you tried any other dap clients to compare with?
Just saw this! @svaante
I remember the screen redraw performance on Mac OS to be abysmal :( I'm on Linux with PGTK support, so it's a bit snappier over here I think.
At some point, it might be worth investigating what causes redraws, and try to limit that? May be that Emacs is re-rendering more often than it needs to?
@timcharper In latest release dape debounces calls to info buffer reverts which should improve redraw performance, also the new json parsing on emacs master is noticable.
In this feature, we add the interactive function
dape-doctor
to check configuration and present warnings or errors to the user if any known configuration issues are detected.