From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Eric M. Ludlam" Newsgroups: gmane.emacs.devel Subject: CEDET speed issues [was Re: Efforts to attract more users?] Date: Sun, 11 Jul 2010 21:57:21 -0400 Message-ID: <4C3A7681.8070003@siege-engine.com> References: <4C37108C.3040207@siege-engine.com> <87y6dkoncz.fsf@aott.dev.webwasher.com> <87vd8od8rs.fsf@linux.vnet.ibm.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1278899021 20514 80.91.229.12 (12 Jul 2010 01:43:41 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 12 Jul 2010 01:43:41 +0000 (UTC) Cc: fplemma@gmail.com, Alex Ott , rms@gnu.org, joakim@verona.se, emacs-devel@gnu.org To: "Aneesh Kumar K. V" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 12 03:43:39 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OY83V-0005iK-RC for ged-emacs-devel@m.gmane.org; Mon, 12 Jul 2010 03:43:39 +0200 Original-Received: from localhost ([127.0.0.1]:48446 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OY83U-0000PE-Cl for ged-emacs-devel@m.gmane.org; Sun, 11 Jul 2010 21:43:36 -0400 Original-Received: from [140.186.70.92] (port=57932 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OY83M-0000Oz-Gk for emacs-devel@gnu.org; Sun, 11 Jul 2010 21:43:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OY83L-0002AC-Ai for emacs-devel@gnu.org; Sun, 11 Jul 2010 21:43:28 -0400 Original-Received: from bird.interbax.net ([75.126.100.114]:57656) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OY83L-00029y-5p for emacs-devel@gnu.org; Sun, 11 Jul 2010 21:43:27 -0400 Original-Received: (qmail 935 invoked from network); 11 Jul 2010 20:43:24 -0500 Original-Received: from static-71-184-83-10.bstnma.fios.verizon.net (HELO ?192.168.1.201?) (71.184.83.10) by interbax.net with SMTP; 11 Jul 2010 20:43:24 -0500 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20091222 Shredder/3.1a1pre In-Reply-To: <87vd8od8rs.fsf@linux.vnet.ibm.com> X-detected-operating-system: by eggs.gnu.org: Windows 98 (1) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:127080 Archived-At: On 07/09/2010 10:33 AM, Aneesh Kumar K. V wrote: > On Fri, 09 Jul 2010 14:23:24 +0200, Alex Ott wrote: >> Re >> >> Eric M. Ludlam at "Fri, 09 Jul 2010 08:05:32 -0400" wrote: >> EML> On 07/08/2010 11:05 PM, Richard Stallman wrote: >> >> The Eclipse IDE has some nice features. Maybe CEDET gives us some of >> >> them, but maybe we still lack some. >> >> EML> In some ways CEDET is "better" that Eclipse (code completion in C/C++ is better), and in >> EML> others it falls behind, such as project management. (This I gather from comments I've >> EML> read). >> >> The biggest problem with CEDET is speed, > > This is one of the main issue i also have. I would really like some of > the CEDET related operation pushed to background and make it don't > effect my editing task. But otherwise I am really happy with the > feature provided. When CEDET is all-on, it certainly is busy anytime it first hits a project. It has to parse all the files and discover the extent of your project. In general, it postpones doing stuff as long as possible into idle time. If a user opens some new big file in some big project for the first time, scrolls down and hits "complete" on a line, it will go off into la-la land for a while to perform the operation. If the user instead opens that project browses around, gets a cup of coffee, and comes back and asks for a completion, it will be quite fast, often less than a second even on a relatively large project (think Linux Kernel sized.) When CEDET is doing busy-work during idle time, it should always be interruptible. If you press something like C-v or other nav command, it should stop and go do that instead. If it doesn't then there is clearly a loop in part of the code that needs the interrupt handler added. I've noticed this parsing big files sometimes but haven't found a good candidate spot to add the check. If a particular kind of completion always takes a long time, there is a profiler setup command you can use to capture your case for analysis in semantic-elp.el. It will save the results making it easier to share the results. My longer term plans involve pushing chunks of the busy work off to a separate process to avoid much of these problems. I also need the separate process to offload the database information from the Emacs process, keeping most of it on disk unless asked-for. Super large projects (like what I work on at work) will cause your whole machine to slow down because Emacs' working set gets so huge. (Eight Gig And Constantly Swapping?) My current thoughts on making this work is to create a separate standalone program to be run as service, much the way databases like Postgres is a service. It would fire off multiple "emacs -batch" slaves running CEDET which it would use to collect and process data. It would then manage disk files of Tag data, possibly in some new format. User run Emacses would also run CEDET, and connect to this service as a classic semanticdb backend. To me, this seems like the only way to maximize code re-use while also getting the desired work offload from the main Emacs process. I'll probably start digging into that seriously around November this year, but I'll be happy to discuss it before then if anyone has ideas for implementation short-cuts, etc. Eric