search

MarcWeber / hasktags

Produces ctags "tags" and etags "TAGS" files for Haskell programs
Other
127 stars 32 forks source link

Switch back to strict ByteStrings #60

Closed vvv closed 5 years ago

vvv commented 5 years ago

Lazy ByteStrings fail on large projects due to too many open files. The error message:

openBinaryFile: resource exhausted (Too many open files)

Fixes #57.

hasktags is a very important development tool. AFAIK, it's the go-to tool for navigating Haskell codebases.

The project I'm working on has 50K+ SLOC of Haskell code. hasktags is the most efficient way to navigate it. After I updated hasktags recently, I discovered that it doesn't work with my project any more.

@jhenahan wrote:

Yup, this happened when I switched from strict to lazy bystestrings. It led to much better performance characteristics, but it seems to be a bit sloppier about managing file handles.

“Make it work” is way more important than “make it work fast”. :)

The problem had been reported almost 3 months ago... Let us fix it, shall we?

vvv commented 5 years ago

[switching from strict to lazy bytestrings] led to much better performance characteristics

IMHO, hasktags with strict bytestrings is performant enough. E.g., it takes less then a second to process the 50K+ SLOC project I mentioned earlier.

$ time hasktags --etags .

real    0m0.720s
user    0m0.528s
sys     0m0.074s

This execution time is perfectly fine for my use case (I don't rebuild tags often).

k-bx commented 5 years ago

:+1: I can confirm this doesn't go OOM on ghc repository but fails with this error (probably unrelated):

➜  ghc git:(master) hasktags -e .
hasktags: src/Hasktags.hs:418:47-63: Non-exhaustive patterns in lambda
k-bx commented 5 years ago

Made a PR https://github.com/MarcWeber/hasktags/pull/61