[darcs-users] GSoC: network optimisation vs cache vs library?

Max Battcher 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
>> server.)
>
> 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 
long-running processes.

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 
optimization".

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?

--
--Max Battcher--
http://worldmaker.net


More information about the darcs-users mailing list