On 2021-02-13 Brett Okken wrote:
> We can make it look even more like liblzma :)

It can be done but I'm not sure yet if it should be done. Your
implementation looks very neat though. :-)

> In my benchmark I observe no negative impact of using the functions.
> Which is to say that this is still 5-7% faster than the byte-by-byte
> approach.

With a dumb test with XZDecDemo, it seems faster than the current code
(8.5 s vs. 7.9 s). However, if I misalign the buffer in XZDecDemo.java
like this

    int size;
    while ((size = in.read(buf, 1, 8191)) != -1)
        System.out.write(buf, 1, size);

then both versions are about as fast (7.9 s). The weird behavior with
misaligned buffers was discussed earlier.

My point is that if tiny things like buffer alignment can make as big a
difference as supposedly better code, perhaps the explanation for the
speed difference isn't the code being better but some side-effect that
I don't understand.

On your systems the results might differ significantly and more
information is welcome. With the current information I think the
possible benefit of the fancier code isn't worth it (bigger xz.jar,
more code to maintain). In any case, any further CRC64 improvements
will need to wait past the 1.9 release.

The test file I used contains a repeating 257-byte pattern where each
8-bit value occurs at least once. It is extremely compressible and thus
makes the differences in CRC64 speed as big as they can be with LZMA2.
With real files the differences are smaller.

Lasse Collin  |  IRC: Larhzu @ IRCnet & Freenode

Reply via email to