Maybe it's worse on non-partial repositories, but for example:
$ time darcs cha Makefile --last=1000
...
54.27s real 52.70s user 0.36s system 97% darcs cha Makefile
interesting. i got just over 30s in my first try on this, which
seemed a lot worse than the response on InteractiveUI.hs.
then i tried it again, moving the file after the option, and got 3.8s!?
then i tried the original query again, and got 3.8s there, too!
now, i always seem to get 3.8s.., so i tried without --last
(redirecting output), and get 1m48 the first time, and 28.6s after.
might have something to do with darcs keeping so many
patches in memory that it doesn't play nice with other tasks
wanting to use the same memory.
That's stretching my definition of "a few" :-) And for this to be usable
for a web interface, it really needs to be a sub-second response.
well, it gets fewer after the first try, it seems (practice effect?-).
that is still not sub-second, but helps in interactive use. it also
suggests that a "darcs server process" that holds on to its
memory, and only considers the last 500 or so patches, might
just be able to deliver acceptable, though not responsive,
performance for a basic better-than-nothing web interface?
claus
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
