RE: [platform-core-dev] About the performance of jars and compression :

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

I recall the Ed Burnette was proposing
to compare compressed and uncompressed JARs.  I don't recall seeing
any results.

Jeff

John Arthorne/Ottawa/IBM@IBMCA
Sent by: platform-core-dev-bounces@xxxxxxxxxxx

07/05/2005 05:12 PM

Please respond to
"Eclipse Platform Core component developers list."

To	"Eclipse Platform Core component developers list." <platform-core-dev@xxxxxxxxxxx>
cc
Subject	RE: [platform-core-dev] About the performance of jars and        compression        : some ideas for plugins installed as one jar.

I don't think anyone performed any formal measurements.  If you (or
anyone else) would like to run some performance tests with both compressed
and uncompressed JARs, people on this list would love to hear the results!
-- 


platform-core-dev-bounces@xxxxxxxxxxx wrote on 04/07/2005 08:06:19 AM:

> Did anyone compare performance of eclipse with both compressed and
> uncompressed jarred plug-ins? 
>   
> Could someone post numbers in this list if any?
>   
> Many thanks in advance, 
> Artyom. 
> 
> From: platform-core-dev-admin@xxxxxxxxxxx [mailto:platform-core-dev-
> admin@xxxxxxxxxxx] On Behalf Of Jeff McAffer
> Sent: Wednesday, March 09, 2005 05:37
> To: platform-core-dev@xxxxxxxxxxx
> Subject: RE: [platform-core-dev] About the performance of jars and
> compression : some ideas for plugins installed as one jar.
>   
> 
> We have applied an internal tool to obfuscate, inline and reduce the
> runtime jar and found that we got 20-25% size reduction.  We
did not
> do alot of analysis to see where the savings were coming from 
> however.  As we have only done one plugin it is unclear if this
> result will repeat itself. 
> 
> In any event, it turns out that the exercise of identifying publicly
> useful vs internal classes/methods is useful in three contexts: 
> - API/access cleanliness - we are currently debating how to have 
> components specify their exposure so that we can check for 
> unexpected cross plugin references 
> 
> - security - to secure a body of code, you need to know all entry
points. 
> 
> - performance - obfuscation, inlining and reduction all require 
> knowing all entry points into a body of code. 
> 
> If we were able to put together and maintain an accurate list of 
> "exposed" classes and methods, all three of the contexts
would be 
> greatly simplified. 
> 
> Jeff 
> 
> 
> 

> 
> "Philippe Ombredanne" <pombredanne@xxxxxxxx> 
> Sent by: platform-core-dev-admin@xxxxxxxxxxx 
> 02/27/2005 04:36 PM 
> 
> Please respond to
> platform-core-dev 
> 
> To 
> 
> <platform-core-dev@xxxxxxxxxxx> 
> 
> cc 
> 
>   
> 
> Subject 
> 
> RE: [platform-core-dev] About the performance of jars and 
> compression : some ideas for plugins installed as one jar.
> 
>   
> 
>   
> 
>   
> 
> 
> 
> 
> Proguard is one of the most commonly open source used there, AFAIK.
> Typically a lot of the optimizations made by those tools:
> - have been made void by modern optimizing JITs, and optimized JVMs
> (i.e. inlining), but you may still win some by applying them statically,
> bypassing VM warm-up times to discover hotspots, and perform JIT
> optimization.
> - are also detected through design time static analysis like the one
> performed by the JDT, or Checkstyle &  PMD (i.e. detect unused
imports,
> fields, methods,.branches...).
> 
> IMHO, it would be hard to get it to work nicely with Eclipse's notion
of
> published vs. public APIs, and intensive dynamic class loading: the
> amount of work to provide exceptions would be significant.
> And like class ordering, because it might be costly and sensitive,
it
> may be worth only on some very specific sets of critical jars, like
SWT,
> or OSGI, where you may gain a few KB here and there, and a few secs.
> My hunch is that a gentle optimization may be able to get ~5 to 10%
size
> reduction, based on past (non-eclipse) experience at most.
> 
> --
> Cheers
> Philippe
> 
> philippe ombredanne | nexB - Open by Design (tm)
> 1 650 799 0949 | pombredanne at nexb.com
> http://www.nexb.com 
> -----Original Message-----
> From: platform-core-dev-admin@xxxxxxxxxxx
> [mailto:platform-core-dev-admin@xxxxxxxxxxx] On Behalf Of Ed Burnette
> Sent: Saturday, February 26, 2005 11:17 PM
> To: platform-core-dev@xxxxxxxxxxx
> Subject: RE: [platform-core-dev] About the performance of jars and
> compression : some ideas for plugins installed as one jar.
> 
> 
> Has anybody tried a java optimizer/obfuscator on Eclipse jars? Of
course
> it would have to be careful not to munge any public APIs but they
can
> potentially reduce jar sizes significantly. Here are some references:
> 
> http://proguard.sourceforge.net/alternatives.html
> http://proguard.sourceforge.net/
> http://preemptive.com/products/dasho/
> http://jode.sourceforge.net/
> http://www.sable.mcgill.ca/soot/
> http://www.alphaworks.ibm.com/tech/JAX
> 
> 
> 
> 
> From: platform-core-dev-admin@xxxxxxxxxxx
> [mailto:platform-core-dev-admin@xxxxxxxxxxx] On Behalf Of Jeff McAffer
> Sent: Saturday, February 26, 2005 10:54 PM
> To: platform-core-dev@xxxxxxxxxxx
> Subject: RE: [platform-core-dev] About the performance of jars and
> compression : some ideas for plugins installed as one jar.
> 
> 
> 
> We did some experiements with class ordering in the jars.  It
is
> interesting but both costly and quite sensitive.  The classload
order
> depends on, of course, what you are doing.  What you are doing
depends
> on the state of the workspace you open.  This is free to change
from run
> to run.  The lower level plugins are roughly independent of the
> workspace but they also only account for a small fraction of the classes
> loaded in a typical session.   
> 
> Summary, something could be done here but the net benefit is
> questionable since it can only be applied to a limited set of plugins
> effectively. 
> 
> Jeff 
> 
> 
> _______________________________________________
> platform-core-dev mailing list
> platform-core-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-core-dev
> _______________________________________________
> platform-core-dev mailing list
> platform-core-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/platform-core-dev_______________________________________________
platform-core-dev mailing list
platform-core-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-core-dev