search

svaante / dape

Debug Adapter Protocol for Emacs
GNU General Public License v3.0
477 stars 31 forks source link

add optimization section in README #61

Closed timcharper closed 8 months ago

timcharper commented 8 months ago

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.

timcharper commented 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.

timcharper commented 8 months ago

@svaante wdyt ?

timcharper commented 8 months ago

ah, with https://github.com/svaante/dape/commit/e84de3dad6f6071fc83d2b220a76888d0e18d6c6, probably don't need the json rpc checker.

timcharper commented 8 months ago

updated PR to remove dape-doctor json-rpc version checking... I like the approach you have better anyways

svaante commented 8 months ago

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

timcharper commented 8 months ago

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.

timcharper commented 8 months ago

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.

svaante commented 8 months ago

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?

timcharper commented 5 months ago

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?

svaante commented 5 months ago

@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.