[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: async 1.0

From: John Wiegley
Subject: Re: async 1.0
Date: Thu, 21 Jun 2012 16:23:26 -0500
User-agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.1 (darwin)

>>>>> 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)"

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))"

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]