On Fri, 12 Jan 2024 18:45:39 GMT, Glavo <d...@openjdk.org> wrote:
> I generated runtime images using `jlink --compress 2 --add-modules
> java.se,jdk.unsupported,jdk.management` and then ran the following JMH
> benchmark:
>
>
> @Warmup(iterations = 10, time = 2)
> @Measurement(iterations = 5, time = 3)
> @Fork(value = 1, jvmArgsAppend = {"-XX:+UseG1GC", "-Xms8g", "-Xmx8g",
> "--add-exports=java.base/jdk.internal.jimage=ALL-UNNAMED"})
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @State(Scope.Benchmark)
> public class Decompress {
>
> private static final ImageReader READER =
> ImageReaderFactory.getImageReader();
> private static final ImageLocation LOC = READER.findLocation("java.base",
> "java/lang/String.class");
>
> @Benchmark
> public ByteBuffer test() {
> return READER.getResourceBuffer(LOC);
> }
>
> }
>
>
>
> This is the result:
>
>
> Zip
>
> Benchmark Mode Cnt Score Error Units
> Score Error Units
> Decompress.test avgt 5 194237.534 ± 1026.180 ns/op
> 152855.728 ± 16058.780 ns/op (-21.30%)
> Decompress.test:gc.alloc.rate avgt 5 1197.700 ± 6.306 MB/sec
> 464.278 ± 47.465 MB/sec
> Decompress.test:gc.alloc.rate.norm avgt 5 243953.338 ± 5.810 B/op
> 74376.291 ± 2.175 B/op (-69.51%)
> Decompress.test:gc.count avgt 5 2.000 counts
> 1.000 counts
> Decompress.test:gc.time avgt 5 4.000 ms
> 3.000 ms
>
>
> The results show that memory allocation is reduced by 70% while decompression
> speed is significantly improved.
It'd be very interesting to see zstd compression applied in this context to see
how it'd stack up w.r.t archive size, speed of decompression and so on.
In this specific case we'd probably have to keep the 4-byte magic marker intact
(it might be possible to rid us of this), then compress the remainder (25
bytes) and store the size (a byte might be enough). For reference with regular
zip on representative data I can squeeze headers down then from 29 to 22-24
bytes. In #17433 I'm down to 12 bytes (including marker) with little to no
overhead. I'm not going to pursue getting #17433 integrated (for now), but it
might be a nice little piece of a larger puzzle.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/17405#issuecomment-1892883726
