Re: async 1.0

[John Wiegley]

>>>>> Richard Stallman <address@hidden> writes:

>     async.el uses `start-process' to spawn a child Emacs process for the
>     purpose of invoking the lambda that is passed as the first argument to
>     `async-start'.

> I see it would work, but wouldn't it be horribly slow to start up?

You know, Emacs is suprisingly fast to execute if you use "emacs -batch -Q".
For example:

    vulcan ~ $ average -n 100 emacs -Q -batch --eval "(+ 10 20)"
    0.0393513631821

It's only 39.4ms overhead per invocation to use Emacs this way -- plus the
time required load modules used by the async process, and injection of the
variable environment.  For example:

    vulcan ~ $ average -n 100 emacs -Q -batch \
                    --eval "(progn (require 'smtpmail) (+ 10 20))"
    0.143285052776

Now we're up to 143ms.  What makes this OK is that the job I'm asking
`async-start' to do takes many seconds, such that the overhead of starting a
new Emacs interpreter is completely lost in the time required to do the work
-- time otherwise spent with me staring at a wait cursor.

As a further example: In Gnus, hitting M-g on the emacs-devel group takes
around 60s (I have a lot of back articles).  If async.el were integrated, this
operation would return instantly, with some kind of fontification to show the
group being updated in the background, and blocking behavior if I hit RET to
actually visit the group before it's done.

That's kind of how dired-async.el operates now: When you copy a bunch of large
files, control returns to you immediately, and each file is colorized with a
yellow background that gets removed once that copy operation is completed.

John