Jakub Narebski wrote:
1. Caching data * disadvantages: - more CPU - need to serialize and deserialize (parse) data - more complicated
CPU: John told me that so far CPU has *never* been an issue on k.org. Unless someone tells me they've had CPU problems, I'll assume that CPU is a non-issue until I actually run into it (and then I can optimize the particular pieces where CPU is actually an issue).
Serialization: I was planning to use Storable (memcached's Perl API uses it transparently I think). I'm hoping that this'll just solve it.
It's true that it's more complicated. It'll require quite a bit of refactoring, and maybe I'll just back off if I find that it's too hard.
I'm afraid that implementing kernel.org caching in mainline in a generic way would be enough work for a whole GSoC 2008.
I probably won't reimplement the current caching mechanism. Do you think that a solution using memcached is generic enough? I'll still need to add some abstraction layer in the code, but when I'm finished the user will either get the normal uncached gitweb, or activate memcached caching with some configuration setting.
By the way, I'll be posting about gitweb on this mailing list occasionally. If any of you would like to receive CC's on such messages, please let me know, otherwise I'll assume you get them through the mailing list.
-- Lea -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
