Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

discussion: would it be worth adding warnings for suboptimal configuration? #45

Open
timcharper opened this issue Dec 30, 2023 · 5 comments

Comments

@timcharper
Copy link
Contributor

timcharper commented Dec 30, 2023

I personally noticed dape performed worse before changing GC and read-process-output-max, wondering if it'd make sense to add warnings if:

  • read-process-output-max is at the default (4096)
  • If gc-cons-threshold is at the default (800000).
  • If (json-available-p) returns non-true (--with-json flag during build, should be turned on for most distros).

I also think the default debug logging settings substantially slow down Emacs for dape and should probably be tuned. dape should probably emit a warning if logging is aggressive, that it will impact the performance of dape.

@svaante
Copy link
Owner

svaante commented Dec 30, 2023

Sounds like an good idea. Currently I am working on removing dapes own parsing with jsonrpc and then the logging will be from jsonrpcand not dape so let's revisit this when I am done with the change 👍

@timcharper
Copy link
Contributor Author

ok, sounds like json-rpc probably remove the need for this, so I'll close for now.

@svaante
Copy link
Owner

svaante commented Jan 5, 2024

jsonrcp is now on master, but I don't believe that will come with any great performance improvements so I'll go ahead and reopen this issue

@svaante svaante reopened this Jan 5, 2024
@timcharper
Copy link
Contributor Author

I can contribute this

@timcharper
Copy link
Contributor Author

I closed the dape-doctor PR since, with time, I'm not actually convinced this is the way to go. Code to help you optimize Emacs belongs in another package, not in a debug backend package.

Also, the benefits are not super clear with my rough, unscientific, terrible benchmarks. In light projects: no difference. In larger projects (where it takes 20-30s to reach the breakpoint), I saw maybe a 10-20% improvement. In light of that, probably warrants a mention in the docs. IDK if the README is the right place for it though, happy to stick it somewhere in the Wiki to be forgotten if you prefer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants