[darcs-users] GSoC: network optimisation vs cache vs library?
me at worldmaker.net
Sat Apr 17 08:12:09 UTC 2010
On 4/17/2010 2:34, Alberto Bertogli wrote:
> On Fri, Apr 16, 2010 at 02:02:11AM -0400, Max Battcher wrote:
>> Alberto Bertogli wrote:
>>> As I mentioned above, I don't see how this is a web scalability issue. A gui
>>> frontend would show the same behaviour, because it's the one displayed by
>>> darcs itself.
>> A GUI frontend would have progress indicators and probably also the
>> ability to cancel long-running tasks (just as darcs itself has progress
>> indicators and responds to Ctrl+C). It would be unlikely for a
>> well-built GUI to accidentally spawn too many darcs processes and
>> entirely disrupt a system. Whereas a web server might see random,
>> accidental or belligerent/disruptive surfing of a web server, and
>> accidentally spawn too many processes. (Which was the issue I was
>> primarily responding to: Trac+Darcs spawning a "large" number of
>> simultaneous darcs processes that ate up all the CPU/memory of the web
> Yes, but I think that's missing the point.
> No amount of UI is going to make a darcs operation faster.
> I think the issue here was how the darcs operation was slow, not the tricks
> trac uses/can use to handle it better and be more friendly about it.
"You go to war with the army that you have-- not the army that you might
want or wish to have at a later time". It seems to me diligent for a
tool like Trac+Darcs to understand the performance characteristics of
the processes that it spawns using today's version of darcs, not some
faster, better, smarter version of darcs that probably will exist at
some point in the future.
Yes, UI won't make the operation faster, but it can *better the
experience*. Zooko reported that "darcs brought his server down" and
made it unresponsive. That's a bad experience, no matter how you slice
it, but in terms of *immediate* responsibility for that bad experience
it wasn't actually "darcs brought the server down", but "Trac spawned
more darcs processes than my server could handle". I think the first
issue here is that Trac(+darcs) can and should better the experience of
A better user experience of third party tools is good for darcs. At some
point (hopefully later rather sooner, touch wood) darcs is going to hit
a point of diminishing returns from performance work, and the time will
come when experience optimization is the only real work to be done to
keep people happy using darcs-based third-party tools. But I wouldn't
save experience optimization for after darcs hits that point of
diminishing returns; there is no such thing as "premature experience
I'm pretty sure that I'm not missing the point, only that I think I'm
not very well elucidating mine (and I'm sorry that I've been very bad at
that in this thread): performance gains are great for everyone, but they
aren't the start and end of everyone's problems, regardless if they are
perceived that way... and the provided example was one in particular
where it seemed to me that the perceived problem wasn't the real problem
in the scenario. Even if the best long-term solution is to increase
darcs performance, the immediate, nearest-term solution is to improve
Trac+darcs and provide a good experience for users of today's versions
of darcs. Does that make sense?
More information about the darcs-users