Max Battcher wrote: > Ultimately, however I think worrying about libdarcs in this case is a > red herring: the first focus should be performance. Given CLI commands > that run nearly as fast as their git counterparts is probably more > useful to everyone involved (even with shell-scripting > interop/marshalling concerns).
I thought this an important enough paragraph to republish above the fold. It seems to me that a good portion of the call for a libdarcs is centered around performance/marshalling issues. It seems to me that if you think that libdarcs will impact a third-party application significantly in performance, on release, there are only a couple of assumptions to draw: 1) Haskell's shell IO is slow. 2) Darcs' use of shell IO is slow. 3) Third-party's language system calls are slow. 4) Third-party's language (xml, regex) parsers are slow. I doubt that (1) and (2) are the case, and (3) and (4) are issues of learning/experience more than darcs issues. At least in my experience it seems that shell IO and parsing are very rarely the bottle neck... The bottle neck is almost always Darcs itself and the margin of time difference between scripting Darcs commands and running the commands directly are generally insignificant (by at least one order of magnitude; possibly significant if, or hopefully when, darcs were 100/1000 times faster than it is...). Maybe memory usage is a significant call for a libdarcs... but I still think performance is the important keystone for darcs, as there are often ways in whatever third-party language is in use to mitigate memory usage in parsing (perhaps trading off speed for memory usage). -- --Max Battcher-- http://worldmaker.net _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
