On 5/30/07, Daniel Hazelton <[EMAIL PROTECTED]> wrote:
I just noticed a bug in my testbed/benchmarking code. It's fixed, but I decided to compare version 6 of the code against the *unsafe* decompressor again. The results of the three runs I've put it through after changing it to compare against the unsafe decompressor were startling. `Tiny's` compressor is still faster - I've seen it be rated up to 3% faster. The decompressor, OTOH, when compared to the unsafe version (which is the comparison that started me on this binge of hacking), is more than 7% worse. About 11% slower on the original test against a C source file, and about 6% slower for random data.
Unsafe vs safe is within 10%. Its okay.
However, looking at the numbers involved, I can't see a reason to keep the unsafe version around - the percentages look worse than they are - from 1 to 3 microseconds.
Not just numbers. Most of applications cannot afford to use unsafe versions anyway (like fs people). (well, the compressed-cache people might want those extra
usecs - but the difference will never be noticeable anywhere outside the kernel) DRH
compressed cache people require every single percent of that performance. For now, ccaching is not ready for mainline (many things need to be done). So, till then I will keep off the unsafe version. If ever compressed caching is on its way to mainline _then_ I will try and add back the unsafe version. But I see no other project that really cares about unsafe version so it's okay to keep it off. - Nitin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
