Re: Speeding up Flymake in emacs-lisp-mode

[João Távora]

Noam Postavsky <address@hidden> writes:

> On Fri, 2 Nov 2018 at 09:12, Stefan Monnier <address@hidden> wrote:
>>
>> > First, I was under the impression that stdin/stdout for emacs was
>> > not easy.
>>
>> Usually it's not, but when running in batch mode it's not so bad.
>
> Yup, (elisp) Batch Mode:
>
>     input that would normally come from the minibuffer is read from the
>     standard input descriptor.
>
>> > Glad to hear it isn't, but how do I read from stdin?
>>
>> async.el does it with (read t), IIRC.
>
> read-from-minibuffer should also work if non-sexp input is wanted.
>
>>> What do you mean by asynchronous process startup? Isn't that
>>> a "stop-the-world" operation however it is invoked?
>
> The subprocess created by make-process (or start-process) doesn't
> block the parent Emacs, it runs in parallel.
>
> (benchmark
>  1 '(call-process (concat invocation-directory invocation-name)
>                   nil nil nil "-Q" "--batch"))
> ;=> "Elapsed time: 0.185000s"
>
> (benchmark 1 '(start-process
>                "emacs" nil (concat invocation-directory invocation-name)
>                "-Q" "--batch"))
> ;=> "Elapsed time: 0.031000s"
>

Of course I know it runs in parallel :-), but creating the process is
20x slower on windows.

   (benchmark 1 '(start-process
                  "emacs" nil (concat invocation-directory invocation-name)
                  "-Q" "--batch")) ;=> "Elapsed time: 0.679212s"

But now I see what you mean, I think!  You mean just put another
long-running emacs, reading sexps from stdin, but shielding the main
emacs from doing the slow process creation?

That should indeed improve things a lot and seems like a fairly clean
solution (even if it still means lots of processes): I think flymake
users are more or less OK with a long delay between typing and seeing
annotations, they just don't want this process to slow down actual
typing and editing.

João