Thread: [cedet-semantic] cedet over tramp too slow?
Brought to you by:
zappo
From: Rodrigo A. <ram...@la...> - 2013-01-17 20:47:05
|
Hi, now that I have a functionally correct setup to auto complete (M-TAB, complete-symbol) on a remote machine over tramp, I have now populated 'include-path' in my remote ede project with 45 include directories. 1. every time I start emacs in a file in that remote project it will take ~25 seconds to go through the init file. It seems to me that emacs is accessing each directory in include-path. 2. every time I try to auto complete for the first time in a cpp file then it will take more than 3 minutes to offer available matches. After that auto completion works fast fast. After restarting emacs on the SAME cpp file that behavior repeats. #1 above seems to be normal, probably unavoidable. But what's the actual reason for cedet to access those directories before being actually used for anything? #2 is a bit of a mystery. Why is that the semantic's cache (which is locally stored in my laptop) does not help on every emacs restart? On the other hand, locally in my laptop using the same source code tree, #1 and #2 are no issues. All is fast fast. Neat! Back in Oct 2011 there was a similar posting. From there I took that #2 above seems not to match expectations. It does not seem that the cache is being used in my case. many thanks in advance for any help, Rodrigo |
From: David E. <de...@ra...> - 2013-01-17 21:12:58
|
Rodrigo Amestica writes: > #1 above seems to be normal, probably unavoidable. But what's the > actual reason for cedet to access those directories before being > actually used for anything? > > #2 is a bit of a mystery. Why is that the semantic's cache (which > is locally stored in my laptop) does not help on every emacs restart? I once tried to use CEDET via Tramp, and yes: it is slow. The main reason is latency. While CEDET will work with the local cache, it still has to check if the cache is still valid, and it does so by checking the files' timestamps. Since you have to check all the dependencies of a single file, this can easily amount to a *lot* of checks. To speed things up, you should make sure that you're working over a permanent connection. That means if you're using ssh, you should create a master connection which can be shared (see '-M' option). Still, don't expect too much. It is nifty that it actually works, but for larger projects, it is just not feasible. -David |
From: Rodrigo A. <ram...@la...> - 2013-01-17 22:56:24
|
At Thu, 17 Jan 2013 22:12:50 +0100, David Engster wrote: > > Rodrigo Amestica writes: > > #1 above seems to be normal, probably unavoidable. But what's the > > actual reason for cedet to access those directories before being > > actually used for anything? > > > > #2 is a bit of a mystery. Why is that the semantic's cache (which > > is locally stored in my laptop) does not help on every emacs restart? > > I once tried to use CEDET via Tramp, and yes: it is slow. The main > reason is latency. While CEDET will work with the local cache, it still > has to check if the cache is still valid, and it does so by checking the > files' timestamps. Since you have to check all the dependencies of a > single file, this can easily amount to a *lot* of checks. > wouldn't be there a way to send #1 and #2 to background? such that emacs startup should look just normal and only if I try to autocomplete before they are done then I would need to wait for long time. many thanks, Rodrigo > To speed things up, you should make sure that you're working over a > permanent connection. That means if you're using ssh, you should create > a master connection which can be shared (see '-M' option). Still, don't > expect too much. It is nifty that it actually works, but for larger > projects, it is just not feasible. > > -David > > ____________________________________________________________________________________ > Simply the Best Information on Cheap Here! > http://click.lavabit.com/4sota9w9j9wtn71rnrx9rzrjp4j9kkytdfh8y65z5usuaiyo5y5b/ > ____________________________________________________________________________________ |
From: Eric M. L. <er...@si...> - 2013-01-18 02:23:59
Attachments:
semantic.db.el.patch
|
Hi Rodrigo, It isn't possible to run anything in the background in Emacs. Semantic does it's best to parse files and such during idle time, but that is a bit different. If you ask for a completion, the assumption is you want the right answer right now. Not much to do about that but resolve everything. For your purposes, the attached patch might help, though I don't know if it will be enough. In this patch, if you promise to only edit your files in Emacs, and not use some other program to change them, then Emacs can skip checking all that stuff David was talking about in his email. You will also need to set the ede inode tracking off to disable the other place where file attributes are accessed frequently. File attribs will still be checked during cache writes and a few other cases, but that is during idle time. If you set the new variable in the patch to t and make the promise, but things are still slow, then the time is probably off doing file name and path lookups. That will require serious infrastructure to build up an internal cache of file names to check for this purpose, and that would be better suited to a tramp feature. Good Luck Eric On 01/17/2013 05:56 PM, Rodrigo Amestica wrote: > At Thu, 17 Jan 2013 22:12:50 +0100, > David Engster wrote: >> >> Rodrigo Amestica writes: >>> #1 above seems to be normal, probably unavoidable. But what's the >>> actual reason for cedet to access those directories before being >>> actually used for anything? >>> >>> #2 is a bit of a mystery. Why is that the semantic's cache (which >>> is locally stored in my laptop) does not help on every emacs restart? >> >> I once tried to use CEDET via Tramp, and yes: it is slow. The main >> reason is latency. While CEDET will work with the local cache, it still >> has to check if the cache is still valid, and it does so by checking the >> files' timestamps. Since you have to check all the dependencies of a >> single file, this can easily amount to a *lot* of checks. >> > > wouldn't be there a way to send #1 and #2 to background? such that > emacs startup should look just normal and only if I try to > autocomplete before they are done then I would need to wait for long > time. > > many thanks, > Rodrigo > >> To speed things up, you should make sure that you're working over a >> permanent connection. That means if you're using ssh, you should create >> a master connection which can be shared (see '-M' option). Still, don't >> expect too much. It is nifty that it actually works, but for larger >> projects, it is just not feasible. >> >> -David >> >> ____________________________________________________________________________________ >> Simply the Best Information on Cheap Here! >> http://click.lavabit.com/4sota9w9j9wtn71rnrx9rzrjp4j9kkytdfh8y65z5usuaiyo5y5b/ >> ____________________________________________________________________________________ > > > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122712 > _______________________________________________ > cedet-semantic mailing list > ced...@li... > https://lists.sourceforge.net/lists/listinfo/cedet-semantic > |
From: Rodrigo A. <ram...@la...> - 2013-01-19 03:06:53
|
Hello Eric, I do not see the patch having any apparent effect. #1 (emacs startup) and #2 (first look up for auto completion) are both still very slow. (I applied the patch and then I byte-compiled the patch file, I also settle the 'promise' variable to t). I have tried all this from home, connected to the remote machine over a typical ISP. Next week I will try all this again from within the intranet at work (remote machine is there), where I also use the same tramp scheme from my laptop. many thanks, Rodrigo |
From: Eric M. L. <er...@si...> - 2013-01-19 03:54:12
|
On 01/18/2013 10:06 PM, Rodrigo Amestica wrote: > Hello Eric, > > I do not see the patch having any apparent effect. #1 (emacs startup) > and #2 (first look up for auto completion) are both still very > slow. (I applied the patch and then I byte-compiled the patch file, I > also settle the 'promise' variable to t). > > I have tried all this from home, connected to the remote machine over > a typical ISP. Next week I will try all this again from within the > intranet at work (remote machine is there), where I also use the same > tramp scheme from my laptop. Well, that's what I get for trying something without running the profiler first. The right thing to do now is use elp, the emacs lisp profiler. The very first completion attempt will always be pretty slow as it loads in files, so you can try elp on that. Semantic has a handy wrapper around ELP to help figure out what's going on. M-x load-library RET semantic/elp RET Put cursor someplace to complete M-x semantic-elp-analyze RET It will save the run into an elp file I'll be able to load in later. You can also enjoy a bit of browsing through the results to see what the big hitters are. The browser lets you resort the results for different criteria. I don't recall all the keystrokes anymore though. Good Luck Eric |
From: Rodrigo A. <ram...@la...> - 2013-01-21 16:11:54
|
Hello Eric, after running semantic-elp-analyze then I never get to "Save Profile to:" (which I see at the end of the function in semantic/elp.el). And I do not find a way to save the buffer *#<semantic-elp-object-analyze ELP> DDEBUG* in a consistent way. It saves to ascii file only what I see on the screen after opening a few entries under eieio-class-definition, which seems to be the only interesting thing in the buffer. thanks, Rodrigo |
From: Eric M. L. <er...@si...> - 2013-01-31 00:23:45
|
On 01/21/2013 11:11 AM, Rodrigo Amestica wrote: > Hello Eric, > > after running semantic-elp-analyze then I never get to "Save Profile > to:" (which I see at the end of the function in semantic/elp.el). And > I do not find a way to save the buffer > > *#<semantic-elp-object-analyze ELP> DDEBUG* > > in a consistent way. It saves to ascii file only what I see on the > screen after opening a few entries under eieio-class-definition, which > seems to be the only interesting thing in the buffer. Hi, Sorry for the delay in resolving this. The ELP support apparently hasn't been used in a long time. It had bugs related to changes in emacs, support libraries like data-debug. I've checked in some changes that should correctly fix up data-debug buffers so you can observe them, and also to correctly save the data files. It should ask for a file to save them in. In the data-debug buffer, you should be able to open up the results, and sort them in different ways, and you may quickly discover where all the time is being spent. Good Luck Eric |