On 6/30/06, Rob Church <robchur(a)gmail.com> wrote:
On 30/06/06, Domas Mituzas
<midom.lists(a)gmail.com> wrote:
But still, it is a eye candy, that requires quite
a lot of resources...
You call it eye candy, I call it an interesting and potentially damn
useful feature idea. Running a web site that gets upwards of ten
thousand odd hits per second, allowing any old web user to edit it,
etc. etc. also requires resources.
I don't think of this as anything remotely like eye candy. In fact it will
save resources over manually looking for who is responsible for a
particular change if it is not recent. Something I already do. Of course
with a handy tool for this, people will use it several orders of magnitude
more often than they now do manually.
Andrew Dunbar (hippietrail)
How do we handle the hit rate? Caching. Squids, shared
memory caching
and opcode caching, not to mention encouraging the client side cache
where possible. Our resources evolve to meet our needs. We can adapt
to what our code base is doing.
Sure, unreasonable and needless performance drains are a bitch, and
I'm all for eradicating them. But the emphasis is on unreasonable and
needless.
I'm well aware of the issues that the innocuous phrase "caching diffs"
brings up, hence the "...". But here we have an interesting proposal -
it's new born, it might not have the cleanest implementation, and it
might turn out to be a load of bollocks. You won't known until we've
examined it in more detail.
So performance is an issue. When is it not?
Rob Church
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
--
http://linguaphile.sf.net