[Top][All Lists]

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

Re: Release plans

From: Thomas Lord
Subject: Re: Release plans
Date: Sat, 30 Aug 2008 16:07:51 -0700
User-agent: Thunderbird (X11/20060808)

Thien-Thi Nguyen wrote:
So no, i don't think the bottleneck would be the buffer access (for this
design), because the subprocess does not really need to access the buffer.
Changes to the buffer that have not yet hit the filesystem can be
communicated by publishing some portion of `buffer-undo-list' (which is
also relatively lightweight).

So, the sub-process basically contains a text editor
in this design, albeit one without redisplay code and
with an unusual, limited command set.   That need for
redundant code to make this thing work helps to prove
that, indeed, the absence of dynamic loading (including
just shared memory regions for buffers) creates make-work
to work around it.

I'm also skeptical about the performance claims here.
A full update involves changing the buffer, print + system
calls to inform the sub-process, system calls + read to
get back the results of the parse updates, and then the
actual text property updates.     For interactive typing
that can probably keep up on a modern machine but
for other stuff it can easily be a performance bottleneck.
(Still, even if it is not, it's doing it "the hard way".)

   and it can be very costly to pass that text to the subprocess and
   then process the returned value (which may look like a list of text
   properties to add to various parts of the text).


   A DLL could be significantly more efficient.  The difference can be as
   large as "on-the-fly" vs "batch".

...i suppose i'll have to agree that all these "could be" scenarios are
possible.  My view is that given the requirement of external symbol tables
(and other state), the biggest win for both performance and maintainability
is to go asynchronous.  If you want async from a subprocess, no worries,
but if you want async in-process, you need to either design (and debug and
maintain) "ethreads", or make Emacs play nice w/ pthreads or quickthreads
or phase-of-the-moon-threads or whathaveyou.  Then, you need to make sure
every visitor treats your program counter w/ the respect it deserves.
That's a lot of thankless and brutish police work.

That seems exaggerated.   A hook in the interact loop that locked
a shared mem buffer briefly while asking for updates from an
incremental parser / ide-helper doesn't seem like it would be all that
hard to get right.


reply via email to

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