[darcs-users] Darcs Wiki Engine

[Max Battcher]

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