commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Janek Bogucki <...@studylink.com>
Subject RE: Enhance performance by generating jar file with -0 option
Date Wed, 24 Mar 2004 10:31:41 GMT
On Mon, 2004-03-22 at 18:02, Gary Gregory wrote:
> I cannot say that I am in favor of this change for several reasons.
> 
> (1) No performance benchmarks. This sounds like a "thought"
> optimization.
> 
> (2) If the classes do take some amount of time T longer load, so what?
> Context is what matters, for instance, for the example I know best, my
> company's app server, if the server takes 20 seconds or 20+T (=?)
> seconds to start, no one cares. Our customers leave the server running
> for days or have policies whereby servers are rebooted every night.
> Oddly enough though, some folks look at our lib directory and count
> bytes and say things like "this is so big and there are so may jars,
> blah blah". So doubling the size of all commons jar files is not going
> to win us any fans. But that's just my case.
> 
> Gary

I agree with Gary. Burdening users with uncompressed jars is the wrong
side of 80/20, in fact it's probably the wrong side of 99/1.

For the record I tested the time it takes to load every class in
collections-3.1-dev with and without compression of the the jar. The
test class is attached.

Jar sizes:

	 525987 commons-collections-3.1-dev.jar
	1097220 commons-collections-3.1-dev-no-compress.jar

Millis to load all classes (5 runs)

	compressed	uncompressed
	
	797		669
	802		680
	796		668
	799		675
	798		675

There is no case for distributing uncompressed jars when the target
application is server side java.

-Janek

Mime
View raw message