This had /way/ more impact than I expected on overall decompression performance.
Here are the baseline numbers for 1.8 (jdk 11 64bit):
Benchmark (file) Mode Cnt
Score Error Units
XZDecompressionBenchmark.decompress ihe_ovly_pr.dcm avgt3
0.731 ± 0.010
On 2021-02-05 Brett Okken wrote:
> > > Now that there is a 6 byte chunkHeader, could the 1 byte tempBuf
> > > be removed?
> >
> > It's better to keep it. It would be confusing to use the same
> > buffer in write(int) and writeChunk(). At glance it would look like
> > that writeChunk() could be
On 2021-02-05 Brett Okken wrote:
> On Fri, Feb 5, 2021 at 11:07 AM Lasse Collin
> wrote:
> > Also, does it really help to unroll the loop? With 8191-byte
> > buffers I see no significant difference (in a quick
> > not-very-accurate test) if the switch-statement is replaced with a
> > while-loop.
> > Now that there is a 6 byte chunkHeader, could the 1 byte tempBuf be
> > removed?
>
> It's better to keep it. It would be confusing to use the same buffer in
> write(int) and writeChunk(). At glance it would look like that
> writeChunk() could be overwriting the input.
I assumed that
On 2021-02-05 Brett Okken wrote:
> After recent changes, the LZMA2OutputStream class no longer uses
> DataOutputStream, but the import statement is still present.
Fixed. Thanks!
> Now that there is a 6 byte chunkHeader, could the 1 byte tempBuf be
> removed?
It's better to keep it. It would be
On Fri, Feb 5, 2021 at 11:07 AM Lasse Collin wrote:
>
> On 2021-02-02 Brett Okken wrote:
> > Thus far I have only tested on jdk 11 64bit windows, but the fairly
> > clear winner is:
> >
> > public void update(byte[] buf, int off, int len) {
> > final int end = off + len;
> >
After recent changes, the LZMA2OutputStream class no longer uses
DataOutputStream, but the import statement is still present.
Now that there is a 6 byte chunkHeader, could the 1 byte tempBuf be removed?
On 2021-02-02 Brett Okken wrote:
> Thus far I have only tested on jdk 11 64bit windows, but the fairly
> clear winner is:
>
> public void update(byte[] buf, int off, int len) {
> final int end = off + len;
> int i=off;
> if (len > 3) {
> switch (i & 3) {
>
> With a file with two-byte repeat ("ababababababab"...) it's 50 % slower
> than the baseline. Calling arraycopy in a loop, copying two bytes at a
> time, is not efficient. I didn't try look how big the copy needs to be
> to make the overhead of arraycopy smaller than the benefit but clearly
> it
On 2021-02-03 Brett Okken wrote:
> I have not done any testing of xz specifically, but was motivated by
> https://github.com/openjdk/jdk/pull/542, which showed pretty
> noticeable slowdown when biased locking is removed. The specific
> example there was writing 1 byte at a time being transitioned
On 2021-01-29 Brett Okken wrote:
> There are several places where single byte writes are being done
> during compression. Often this is going to an OutputStream with
> synchronized write methods. Historically that has not mattered much
> because of biased locking. However, biased locking is being
On 2021-02-03 Brett Okken wrote:
> On Wed, Feb 3, 2021 at 2:56 PM Lasse Collin
> wrote:
> > It seems to regress horribly if dist is zero. A file with a very
> > long sequence of the same byte is good for testing.
>
> Would this be a valid test of what you are describing?
[...]
> The source is
12 matches
Mail list logo
