OCamlPro / ocp-index

Easy access to the interface information of installed OCaml libraries for editors like Emacs and Vim.
http://www.typerex.org/ocp-index.html
Other
62 stars 25 forks source link

recursive directory scanning harmful for performance #76

Open nojb opened 9 years ago

nojb commented 9 years ago

I am using ocp-index with a large source tree (~1000 modules in ~1500 directories). Running

ocp-index complete -I . foo

when standing at the source of the tree incurs in a delay of about 1s before completions appear. While this is not much it is too long to use it for completion in emacs.

Some profiling shows that most of the time is spent traversing the directory tree looking for *.cm{t,ti,i} files. Since the set of such directories are more or less static one should be allowed to specify these directories by hand to avoid the recursive scanning each time ocp-index is run. The following changes are proposed:

find . -name '*.cmt*' -or -name '*.cmi' -exec dirname {} \; | sort | uniq > .ocp-index

while standing at the project root.

Note that the file .ocp-index can also be used to indicate the project root and we could replace all the build system-specific logic easily using this one mechanism. For example, projects using ocamlbuild could simply create a .ocp-index file containing "_build":

echo _build > .ocp-index

I have a small patch implementing this proposal and it gets the delay reduced to < .2s which makes it useful for interactive emacs use again. I would like to submit a pull request, but I am opening this issue first to ask for opinions/ideas/etc.

Thanks!

AltGr commented 9 years ago

Thanks; in my experience, the delay gets below noticable once the os caching has done its job after first run, but that may not always be the case. Ocp-index does already implement some magic to guess your project's root and build directory, though: so whenever a _build is found in a parent directory, both should be inferred from there. (the code is here).

How does ocp-index behave in your case if you remove the -I . ?

So .ocp-index may be a good idea to work around the cases where this doesn't work reliably, if there is no easy fix to the heuristics. I'd like to keep the current defaults which appear to work well for most projects, though.

nojb commented 9 years ago

Just pushed a PR in order to have something more concrete to discuss. If I remove the -I . or if I pass a directory with a small number of subdirectories then ocp-index works fast as usual. Also, the delay does not go away after the first run under Cygwin.

Thanks!