> > Here's a crazy idea: use the POSIX "*at" functions, see man openat for > > an explanation and links to the related functions. The API can be > > emulated on Windows at the performance cost that has already been noted. > > > > The downside of course would be not using the ordinary System.* > > functions and having to write your own binding. Of course such a binding > > would be useful more widely, probably best as an implementation > > substrate in some new IO lib that has an abstract FilePath type. > > Cool, thanks for the suggestion. I did run across openat when doing some > research on the problem, but I had mistakenly got the impression it was > only available on Solaris. > > Doing a good job of the library won't be a quick job, but it sounds worth > doing if we can find someone willing :-) Any volunteers?
Another possibility which uses somewhat less FFI would be to use a different representation of FilePath in darcs. I understand you already do use some different type. One option would be to use a representation like a reverse-order list of path components, with each component stored as a short packed string. That allows for sharing between paths and would reduce the cost of using long absolute paths. You'd still have a conversion via String to use the System.IO functions, but at least that's only temporary garbage so affects just CPU time not overall memory use. Duncan _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
