<br><br><div class="gmail_quote"><div dir="ltr">On Sun, Feb 4, 2018, 12:03 Mads Kiilerich <<a href="mailto:mads@kiilerich.com">mads@kiilerich.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
<div class="m_2968977218115094156moz-cite-prefix">On 02/03/2018 10:12 PM, Dominik Ruf
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_quote">
<div dir="ltr">Mads Kiilerich <<a href="mailto:mads@kiilerich.com" target="_blank">mads@kiilerich.com</a>>
schrieb am Sa., 3. Feb. 2018 um 19:32 Uhr:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On
02/01/2018 12:50 AM, Dominik Ruf wrote:<br>
> Hi all,<br>
><br>
> I'm currently looking at the caching Kallithea does.
And I'm a<br>
> bit...baffled.<br>
<br>
Yes, it is quite baffling and not very efficient.<br>
<br>
I think it very rarely gives any real benefit - it might
even make<br>
things slower. In real world setups with multiple
repositories served by<br>
each worker process, cache hits are quite rare.</blockquote>
<div>For large git repositories we certainly do need caching.</div>
</div>
</div>
</blockquote>
<br></div><div text="#000000" bgcolor="#FFFFFF">
Perhaps. But it is probably a very different kind of caching we
need.</div></blockquote></div><div>Displaying a changelog page with 100 changesets currently takes 54 seconds even with the current caching for the Linux Kernel.</div><div>I'm about to make some changes that will get this down to about 2.5 seconds. But of course this also depends on caching.</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><br>
<br>
/Mads
</div></blockquote></div>