GNU bug report logs -
#58839
29.0.50; project-kill-buffer fails when Eglot is running
Previous Next
Full log
Message #161 received at 58839 <at> debbugs.gnu.org (full text, mbox):
João Távora <joaotavora <at> gmail.com> writes:
> I haven't studied your code in depth, but it seems like you're giving
> `match-buffers/compiled` benchmark 10 times the work you're giving to
> the other function, which would explain why it's 10x slower.
>
You are absolutely right, I re-ran the tests the right way and got these
results:
--8<---------------cut here---------------start------------->8---
(benchmark-run 1000
(match-buffers sample-condition))
;; => (25.052781603 265 16.678798381999997)
(benchmark-run 1000
(match-buffers/compiled sample-condition))
;; (30.021295067 335 21.01291473699999)
--8<---------------cut here---------------end--------------->8---
> The byte-compiler (or the native compiler) can't really optimize the
> mini-language more magically. It can only optimize elisp.
Of course, I don't get why it should?
> My idea of using the byte-compiler to do this is different: it entails
> translating the mini-language to elisp first and then byte-compiling
> that. But it is a technique that I think your code isn't applying
> or at least not correctly (though I haven't read all of it: I will soon).
What I am doing is translating it into lambda expressions, but I could
also try out translating it into an s-expression and passing that to
`eval'...
> You can see eglot's "glob matching" section for the application of
> such a technique the "glob" minilanguage that is required by LSP (iow
> it wasn't "invented by me" ;-) )
This bug report was last modified 2 years and 279 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.