On 9/7/08, Linus Torvalds <torvalds@linux-foundation.org> wrote:
quoted text
>
>
>  On Sat, 6 Sep 2008, Jon Smirl wrote:
>  >
>
> > When I was playing with those giant Mozilla packs speed of zlib wasn't
>  > a big problem. Number one problem was the repack process exceeding 3GB
>  > which forced me to get 64b hardware and 8GB of memory. If you start
>  > swapping in a repack, kill it, it will probably take a month to
>  > finish.
>
>
> .. and you'd make things much much WORSE?

My observations on the Mozilla packs indicated that the problems were
elsewhere in git, not in the decompression algorithms. Why does a
single 2000 delta chain take 15% of the entire pack time? Something
isn't right when long chains are processed which triggers far more
decompressions than needed.


quoted text
>
>
>  > Size and speed are not unrelated.
>
>
> Jon, go away.
>
>  Go and _look_ at those damn numbers you tried to point me to.
>
>  Those "better" compression models you pointed at are not only hundreds of
>  times slower than zlib, they take hundreds of times more memory too!
>
>  Yes, size and speed are definitely not unrelated. And in this situation,
>  when it comes to compression algorithms, the relationship is _very_ clear:
>
>   - better compression takes more memory and is slower
>
>  Really. You're trying to argue for something, but you don't seem to
>  realize that you argue _against_ the thing you think you are arguing for.
>
>
>                 Linus
>


-- 
Jon Smirl
jonsmirl@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html