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
