I'm on emacs using helm-projectile. I notice that emacs startup is very slow, ~4s. And projectile find fuzzy matching is slow as well, when I type the file name in full it takes about ~3s.
I am working on a very large project, ~110K files. Is there someway I can exclude from folders from the search path?
I found a huge speedup by enabling Projectile's caching.
To turn it on, M-x customize-variable for projectile-enable-caching and set it to on.
Docs: https://github.com/bbatsov/projectile/blob/master/doc/configuration.md#caching
Since indexing a big project is not exactly quick (especially in Emacs Lisp), Projectile supports caching of the project's files. The caching is enabled by default whenever native indexing (editor's note: native indexing is for Windows) is enabled.
Related
find is sometimes a bit slow for large directories. This can sometimes be resolved by excluding files and directories.
Is there a version of find that supports caching for better performance. Similar to ctags but for the details about their files rather than their content.
Related:
https://unix.stackexchange.com/questions/78726/find-ls-caching
https://serverfault.com/questions/1006135/can-you-cache-the-find-command (suggests locate)
This answer to this question shows how you can run updatedb on a particular directory and then use locate.
find already does use caching.
Edit: Actually I don't know what it does but the first time you run the command is slower than the rest. Perhaps it's just indicing.
ctags is a simple source code tagging system, also integrated in vi (and its flavours nvi, vim, etc.). AFAIK, it builds a plain text file where all the elements (functions, macros, ...) of the source code are indexed. But this file may become too large and unmanageable when the source code tree is extremely huge: this is the case of a kernel (Linux, *BSD, or similar).
Is still ctags or exuberant-ctags suitable for a complex source tree like a kernel?
If not, what tools (with the same integration in vi as ctags) can replace it? This may become subjective, so if possible provide a list of suggested tools: any comments, and references to a guide with the keyboard shortcuts in vi, are welcome.
Supported languages should be at least C, C++, assembly. The tool should be usable through CLI. I would principally like to jump to the definition of functions, macros, struct and similar objects (with ctags, pressing Ctrl+] with the cursor over the item name), to their manpages if possible, and back to the code.
The only alternative tool I know so far is GNU global, with a pretty complex vi integration, which seems to be possible only through Perl (and I can't find the equivalent of Ctrl+]).
The answer to your first point is a resounding yes.
You can use ctags to generate a tags file for different subtrees, thus keeping the size of the generated file to a minimum. At this point, you need to have a mechanism in place for searching for these multiple tags files. Vim provides this, of course.
I have given some advice here, so you may want to check that out.
Of course, I use exuberant-ctags there, so keep that in mind.
I am using the glew and freeglut libraries (both of which include huge numbers of functions and constants declarations) to write opengl programs under Emacs. I use the CEDET's default semanticdb as the back end of auto-complete at first. However the Emacs freezes and it cost about 20 seconds to pop the candidates of auto-complete when I typing gl(since there is many GL_XXX constants and glxxx function in the header files of glew and glut). the pop-up of the candidate is too slow, is there a way to speed it up still using the CEDET? or is there another way to walk around it? by using the gtags? how?
Since there are so many functions and constants declarations in the header files, I am heavily rely on the auto completion. I am using the CEDET 1.1, does the new version of CEDET solve the problem?
Use of gtags should potentially speedup calculation of alternatives. Does slow completion happens always, or only on first use? This could be caused by parsing header files, etc., and later this should be caches in semanticdb (if you've enabled it)
I am switching to Emacs from TextMate. One feature of TextMate that I would really like to have in Emacs is the "Find in Project" search box that uses fuzzy matching. Emacs sort of has this with ido, but ido does not search recursively through child directories. It searches only within one directory.
Is there a way to give ido a root directory and to search everything under it?
Update:
The questions below pertain to find-file-in-project.el from Michał Marczyk's answer.
If anything in this message sounds obvious it's because I have used Emacs for less than one week. :-)
As I understand it, project-local-variables lets me define things in a .emacs-project file that I keep in my project root.
How do I point find-file-in-project to my project root?
I am not familiar with regex syntax in Emacs Lisp. The default value for ffip-regexp is:
".*\\.\\(rb\\|js\\|css\\|yml\\|yaml\\|rhtml\\|erb\\|html\\|el\\)"
I presume that I can just switch the extensions to the ones appropriate for my project.
Could you explain the ffip-find-options? From the file:
(defvar ffip-find-options
""
"Extra options to pass to `find' when using find-file-in-project.
Use this to exclude portions of your project: \"-not -regex \\".vendor.\\"\"")
What does this mean exactly and how do I use it to exclude files/directories?
Could you share an example .emacs-project file?
I use M-x rgrep for this. It automatically skips a lot of things you don't want, like .svn directories.
(Updated primarily in order to include actual setup instructions for use with the below mentioned find-file-in-project.el from the RINARI distribution. Original answer left intact; the new bits come after the second horizontal rule.)
Have a look at the TextMate page of the EmacsWiki. The most promising thing they mention is probably this Emacs Lisp script, which provides recursive search under a "project directory" guided by some variables. That file begins with an extensive comments section describing how to use it.
What makes it particularly promising is the following bit:
;; If `ido-mode' is enabled, the menu will use `ido-completing-read'
;; instead of `completing-read'.
Note I haven't used it myself... Though I may very well give it a try now that I've found it! :-)
HTH.
(BTW, that script is part of -- to quote the description from GitHub -- "Rinari Is Not A Rails IDE (it is an Emacs minor mode for Rails)". If you're doing any Rails development, you might want to check out the whole thing.)
Before proceeding any further, configure ido.el. Seriously, it's a must-have on its own and it will improve your experience with find-file-in-project. See this screencast by Stuart Halloway (which I've already mentioned in a comment on this answer) to learn why you need to use it. Also, Stu demonstrates how flexible ido is by emulating TextMate's project-scoped file-finding facility in his own way; if his function suits your needs, read no further.
Ok, so here's how to set up RINARI's find-file-in-project.el:
Obtain find-file-in-project.el and project-local-variables.el from the RINARI distribution and put someplace where Emacs can find them (which means in one of the directories in the load-path variable; you can use (add-to-list 'load-path "/path/to/some/directory") to add new directories to it).
Add (require 'find-file-in-project) to your .emacs file. Also add the following to have the C-x C-M-f sequence bring up the find-file-in-project prompt: (global-set-key (kbd "C-x C-M-f") 'find-file-in-project).
Create a file called .emacs-project in your projects root directory. At a minimum it should contain something like this: (setl ffip-regexp ".*\\.\\(clj\\|py\\)$"). This will make it so that only files whose names and in clj or py will be searched for; please adjust the regex to match your needs. (Note that this regular expression will be passed to the Unix find utility and should use find's preferred regular expression syntax. You still have to double every backslash in regexes as is usual in Emacs; whether you also have to put backslashes before parens / pipes (|) if you want to use their 'magic' regex meaning depends on your find's expectations. The example given above works for me on an Ubuntu box. Look up additional info on regexes in case of doubt.) (Note: this paragraph has been revised in the last edit to fix some confusion w.r.t. regular expression syntax.)
C-x C-M-f away.
There's a number of possible customisations; in particular, you can use (setl ffip-find-options "...") to pass additional options to the Unix find command, which is what find-file-in-project.el calls out to under the hood.
If things appear not to work, please check and double check your spelling -- I did something like (setl ffip-regex ...) once (note the lack of the final 'p' in the variable name) and were initially quite puzzled to discover that no files were being found.
Surprised nobody mentioned https://github.com/defunkt/textmate.el (now gotta make it work on Windows...)
eproject has eproject-grep, which does exactly what you want.
With the right project definition, it will only search project files; it will ignore version control, build artifacts, generated files, whatever. The only downside is that it requires a grep command on your system; this dependency will be eliminated soon.
You can get the effect you want by using GNU Global or IDUtils. They are not Emacs specific, but they has Emacs scripts that integrate that effect. (I don't know too much about them myself.)
You could also opt to use CEDET and the EDE project system. EDE is probably a bit heavy weight, but it has a way to just mark the top of a project. If you also keep GNU Global or IDUtils index files with your project, EDE can use it to find a file by name anywhere, or you can use `semantic-symref' to find references to symbols in your source files. CEDET is at http://cedet.sf.net
For pure, unadulterated speed, I highly recommend a combination of the command-line tool The Silver Searcher (a.k.a. 'ag') with ag.el. The ag-project interactive function will make an educated guess of your project root if you are using git, hg or svn and search the entire project.
FileCache may also be an option. However you would need to add your project directory manually with file-cache-add-directory-recursively.
See these links for info about how Icicles can help here:
find files anywhere, matching any parts of their name (including directory parts)
projects: create, organize, manage, search them
Icicles completion matching can be substring, regexp, fuzzy (various kinds), or combinations of these. You can also combine simple patterns, intersecting the matches or complementing (subtracting) a subset of them
Is there a way to improve emacs tramp performance? For me it's faster to open an external ftp client (filezilla), transfer files to the local disk and open them in an external editor (notepad) than open them with emacs.
I use emacs23.1 under windows xp.
I tried different tramp-default-method (telnet, pscp, ftp), all of them have the same performance.
Profiling results with elp-instrument-package are the following (I opened 3 remote files of 1.5 MB each one)
tramp-file-name-handler 1461 350.41599999 0.2398466803
tramp-sh-file-name-handler 1461 350.02699999 0.2395804243
tramp-send-command 227 179.63400000 0.7913392070
tramp-send-command-and-check 205 177.77600000 0.8672000000
tramp-wait-for-regexp 227 176.47800000 0.7774361233
tramp-wait-for-output 226 176.40000000 0.7805309734
tramp-barf-unless-okay 18 133.46699999 7.4148333333
tramp-handle-insert-file-contents 3 132.046 44.015333333
tramp-handle-file-local-copy 3 131.281 43.760333333
tramp-accept-process-output 2375 112.95100000 0.0475583157
So, actual file transfer takes 132 sec, about 1/3 of total time. Why does it spend so much time in tramp-sh-file-name-handler? I tried to advice a function tramp-sh-file-name-handler to store and return cached results but it does not work, probably this function has some side effects.
Any ideas how to improve tramp performance? (I use emacs 23.1 under WindowsXP)
I've found that fuse-ssh is far better than tramp mode, if you can set it up that way.
if your use case improves, use remote client! I have resorted to editing remotely with emacs, this reminds me.
my experience has led me to believe the machine hosting emacs would be the bottleneck
however a better SSH client may help... try the list at OpenSSH.org (low in the left nav) I like PuTTY on Windows, where selection=copy & right-click=paste.
not sure of ways to improve the remote performance, though. the default build of emacs has a lot of lisp but it takes more disk than RAM space, and has always been efficient for me excepting large files & net/sys lag.
if your case has highlighting and auto-features you don't want, then configuring minimally might help - should be able to do that without rebuilding.
emacs is so vast, I noticed most when I found out it can send/receive e-mail. I have hardly explored the tip of the iceberg.
in this case though 'vi' may be better... even with more emacs experience relatively I've used small portions in each camp. rarely do I script or seek out a new feature, the digging is tough but there are handy command guides for both.
I resolved a problem by a couple of scripts which allow me to mget/put and mirror files or directories. These scripts use lftp (a version which is installed with the cygwin) and have a very good performance.
They were demands to publish my solution. Unfortunately, I have only a prototype of it. I have no time to finish it. It serves me well but it's not in the state to be published.