Did you try measuring on eg, edwardk's gl package? On Thu, Nov 20, 2014 at 12:52 PM, Merijn Verstraaten <mer...@inconsistent.nl > wrote:
> Hey, > > I'm not really happy with an explicit extension list passed through flags, > as it seems far to manual. It doesn't strike me as a very significant > problem as my current work-in-progress patch only resorts to scanning the > directory listing if none of the existing extensions are found. > > It seems unlikely that extremely large directories are in the search path. > I don't think we're expecting anyone to have thousands of files in their > module directories (and even thousands would take 0 time to scan...). We > already try all search paths during probing so the extra overhead from > large number of search paths shouldn't be substantially more than we have > now. > > As for the weird FS support, I really don't think it's GHC's job to > support people doing ridiculous things like "compiling on a filesystem that > doesn't support directory listings", I mean, come on! > > To be honest, I consider both directories with huge numbers of files (keep > in mind, we'd only scan the actual module sub-directory AND that we'd need > to run into directories with tens if not hundreds of thousands files to > notice any real slowdown) and weird filesystems that don't support > directory listing cases of "so don't do that, then". Especially since these > are only problems for users using non-standard module extensions. > > Cheers, > Merijn > > > On 20 Nov 2014, at 2:40, Sven Panne <svenpa...@gmail.com> wrote: > > 2014-11-20 9:36 GMT+01:00 Joachim Breitner <m...@joachim-breitner.de>: > >> [...] With your extensions it will have to read the directory contents. > In > >> most situations, that should be fine, but it might cause minor > >> inconveniences with very large directories, many search paths (-i flags) > >> and/or very weird file systems (compiling from a FUSE-mounted > >> HTTP-Server that does not support directory listing? Would work now...) > > > > Hmmm, IMHO reading directory contents is not a good idea for a > > compiler, for just the reasons you mentioned. > > > >> A fixed set of extensions (e.g. just "md" and "tex") would avoid this > >> problem, but goes against the spirit of the proposal. > > > > I think we can get the best of both worlds by adding a compiler flag, > > e.g. --literate-extensions=md,tex. This way the compiler still has to > > probe only a finite set of filenames *and* we are still flexible. > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs