Hi, Miles Bader <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Ludovic Courtès) writes: >> what they think goes wrong (it is true that `tla' is not lightning fast, >> especially without a revlib). > > More accurately, tla is dog-slow and consumes cpu/disk-io like crazy for > most operations (it's slightly better about network-io in terms of bytes > transferred, but goes to town with the worst latency ever). I still use > tla, mind you, but my number one complaint is its insane inefficiency; > maybe darcs is slower, I dunno. I think you already mentioned that, according to you, this inefficiency was more an implementation issue rather than a design issue, is that correct? I did the following experiment: $ strace -o ,,s -e stat,stat64,open tla changes [...] $ wc -l ,,s 7881 ,,s $ tla inventory --source |wc -l 1038 $ tla inventory --all |wc -l 2794 $ find . -name \* |wc -l 6433 (To be fair, the revision in question was already in the revlib, otherwise the number of `open ()' calls yielded by `tla changes' amount to ~17000 since it has to feed my greedy library.) In the end, it looks like there is not *so* much I/O inefficiency due to the implementation itself. The inventory mechanism implies that all files in the tree must be scanned, and the ID-tagging mechanism (I'm using `tagline' here) implies that all the `.arch-ids' directories plus all the source files must be scanned (roughly). Although more flexible, Arch's ID-tagging mechanism probably yields more I/O than "manifests". Thus, it looks like high disk I/O consumption may be due to the design rather than the implementation. Now, it may be the case that the real performance bottleneck is CPU consumption rather than disk I/O, I don't know. Thanks, Ludovic. _______________________________________________ Gnu-arch-users mailing list Gnu-arch-users@gnu.org http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
