Runtime impact of compressing class files in the module library

[Peter Jensen]

No attachments, okay! Here's data in csv format (without the nice 
diagrams:-)


"Read jar entries sequentially",,"Compressed",,"Uncompressed",,"Read 
Overhead"
"CPU Speed (GHz)","msec/M-CPU","Read (msec)","Read Model","Read 0 
(msec)","Read 0 Model",
0.3,3.33,8735,8728,4011,4006,118%
0.6,1.67,4668,4689,2156,2177,115%
0.8,1.25,3674,3679,1731,1720,114%
1,1.00,3093,3073,1451,1446,113%
,0,,650,,348,
"Linear regression",,,,,,
"Constant (msec)",,,650,,348,
"M-CPU cycles",,,2424,,1097,
"Correlation",,,0.99998,,0.99992,
,,,,,,
,,,,,,
"Load Classes – Hashset order",,"Compressed",,"Uncompressed",,"Load 
Overhead"
"CPU Speed (GHz)","msec/M-CPU","Load (msec)","Load Model","Load 0 
(msec)","Load 0 Model",
0.3,3.33,27904,27888,25010,24939,12%
0.6,1.67,15891,15944,14702,14865,7%
0.8,1.25,12947,12958,12116,12347,5%
1,1.00,11213,11166,11158,10836,3%
,0,,3999,,4791,
"Linear regression",,,,,,
"Constant (msec)",,,3999,,4791,
"M-CPU cycles",,,7167,,6044,
"Correlation",,,0.99998,,0.99922,


On 11/09/11 12:18, Peter Jensen wrote:
> Just joining the alias.
>
> I wrote a test program that measures the time to
> 1/ read all API classes in a jar file, in jar entry order
> 2/ load all the same classes by name, in order of Hashset iteration 
> (set populated during read test).
>
> Gary Adam's helped run this on a BeagleBoard, at different CPU speed, 
> using an Embedded SE build,
> with a compressed vs. uncompressed rt.jar. Note: Embedded SE compress 
> by default. I'm not sure
> if it's 'zip -9' or standard zip compression.
>
> Both test show linear dependency between time and cpu speed. That is, 
> the workload
> consist of a component inversely proportional to CPU frequency, and a 
> constant component
> (e.g. IO wait time).
>
> The CPU sensitive component shows a worst-case class-loading overhead 
> of 7 to 6 (17%)
> (worst-case is for an infinitely fast storage. With high CPU to IO 
> performance you get better results).
>
> This for an approx. 50% reduction in jar file size.
>
> Results and regression analysis attached.
>
> -------- Original Message --------
> Subject: Fwd: Compressing class files in the module library
> Date: Wed, 09 Nov 2011 13:27:23 -0500
> From: Gary Adams <gary.adams at oracle.com>
>
>
>
>
>
> fyi
>
> -------- Original Message --------
> Subject: Compressing class files in the module library
> Date: Wed, 09 Nov 2011 18:21:07 +0000
> From: Alan Bateman <Alan.Bateman at oracle.com>
> To: jigsaw-dev <jigsaw-dev at openjdk.java.net>
>
>
>
> I have an initial patch [1] to compress the classes of modules in the
> module library. It essentially adds an option to "jmod create" so that
> the classes of any modules installed into the library get compressed.
> The patch also adds a build option to enable compression in the system
> libraries of the images that the build generates.
>
> Before finishing this I'd like to get some input on a few points. The
> first is whether it's reasonable to enable compression when creating the
> module library? The alternative is install time so that it's on a per
> module basis. The former is less flexible but as the module library
> format evolves it may not be feasible to have a mix of compressed and
> uncompressed modules.
>
> The other question is suggestions for the option name. For now it's -9
> or --enable-compression (-9 influenced by the zip -9 option for
> compress better). I'm looking for better suggestions.
>
> Thanks,
>
> -Alan.
>
> [1]http://cr.openjdk.java.net/~alanb/ModuleLibraryCompression/webrev/
>