emacs-devel
[Top][All Lists]
Advanced

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

CEDET and threads (was Re: Very interesting analysis of "the state of Em


From: Eric M. Ludlam
Subject: CEDET and threads (was Re: Very interesting analysis of "the state of Emacs")
Date: Fri, 2 May 2008 12:50:17 -0400

Hi,

  The stuff CEDET and ECB does has often caused us to wish for any
kind of concurrency.  Right now CEDET/Semantic parses buffers which,
right now, can be quick for reasonably sized buffers, but can be quite
slow for something like emacs/src/lisp.h.  In addition, providing
smart completion requires building large tables to make lookup go
faster.

  I use an idle timer, and do this work at idle time.  The parsing
code and other routines called from the idle timer will `throw' on
user input at key locations, and the next idle time will resume
processing.

  For each task that needs background processing it is required that
it be updated to be interruptible, which makes it that much harder to
move processing to idle time.  A side effect is that when a user
request comes in for some feature, often times there can be a long
wait, depending on the size of the code base.

  I've tuned CEDET to be close to instantaneous for smaller code
bases, but on larger code bases, I sometimes can have a 1 minute wait
building up databases to provide the right answer.  Once I have the
tables on hand, things go quickly again.

  I've toyed with the idea of having a second Emacs as a subprocess to
do some of this work concurrently.  This would free up CEDET to begin
performing speculative parsing to keep the user interaction snappy
when switching around between different sections of large project.
I'm not sure how to transfer the data around though.

  For me, the ideal concurrent task setup would share buffers and
share large lisp data structures that a user might be interacting with
in order to keep parsing data and textual decorations up to date.  It
would also be great if whenever a user typed ".", a concurrent task
could run to get completions, and allow the user to keep typing after
the period.  Once the answer is ready, an inline completion mode could
startup without having to wait for the user to explicitly stop typing.
This is very hard to do using idle timers and cooperative
multitasking.

  Well, this message is longer than I expected.  Suffice it to say
that CEDET could use concurrency at the full shared environment level,
but any kind of concurrency would be helpful.

Eric

-- 
          Eric Ludlam:                       address@hidden
   Siege: www.siege-engine.com          Emacs: http://cedet.sourceforge.net




reply via email to

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