[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [platform-core-dev] About the performance of jars and compression : some ideas for plugins installed as one jar.
|
Title: Message
Now, the only interesting point is the fact that the JVM bundled jars are
shipped uncompressed.
I
guess I would want to make sure that I would have the fastest execution possible
for a JVM...
The
pde export does not offer much options there for now.
Some simple tests could be done ass soon as a stable
31m6 is out.
My
hunch is that uncompressed should be faster.
The
trade off is using more disk space for the installation but that would not
a problem for an IDE config.
A
space conscious RCP or eRCP would probably prefer a compressed
format.
What do you think?
Another question on the topic: are you considering flat or nested jars
(jar libs within jarred plugins)?
--
Cheers
Philippe
philippe ombredanne | nexB -
Open by Design (tm)
1 650 799 0949 | pombredanne at nexb.com
http://www.nexb.com
Philippe,
As you say, which is better is
likely platform dependent. Fast CPU, slower disk favours compression.
etc etc.
Not sure what we
can really do here. People are presumably free to take our drops and
repackage them in the most optimal form for them.
Jeff
"Philippe Ombredanne"
<pombredanne@xxxxxxxx> Sent by: platform-core-dev-admin@xxxxxxxxxxx
02/23/2005 11:04 AM
Please respond
to platform-core-dev |
|
To
| <platform-core-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
| [platform-core-dev]
About the performance of jars and compression : some ideas for
plugins installed as one jar. |
|
Hi,
following a short email exchange with Jeff, I am posting
that to the
list.
The topic is: class/resource loading from jars
compressed or not, or
file system, and performance implications.
Some of
you may have some valuable insights.
The rational I remember was:
-
when loading many classes, dealing with jars is more efficient than
dealing
with deployed .class, avoiding the overhead of many file
systems
calls.
- uncompressed jars do not have to be
decompressed
I made some research about performance of jarred vs.
jarred compressed
vs. deployed class & resource loading and
report.
An interesting reference can be found here
:
http://safari.oreilly.com/JVXSL.asp?xmlid=0-596-00377-3/javapt2-CHP-3-SE
CT-12
Now
in contradiction with that, the folks of knopflerfish/osgi advocate
for the
opposite: a deployed .class format But they really are in the
embedded
world. http://www.knopflerfish.org/download.html
Typically, JRE &
JDK jars are shipped as uncompressed, like the
monstruous rt.jar. There
must be a reason.
I am really not sure how this fares as it is always a
compromise between
IO, memory and CPU.
A lot of pointer in that field
are related to embedded devices and
tradeoffs between network bandwidth,
CPU and memory/storage available on
small devices.
If done right
this could have beneficial implication for Eclipse startup
and
class-loading.
Comments are
welcomed.....
jeff_mcaffer@xxxxxxxxxx wrote:
>Compressed vs.
uncompressed is an interesting observation. Can you
produce some
numbers on this?
> The direction for M6 is to make plugins (and
fragments) ship as
self-contained Jars.
Jeff,
Just as a note
on that topic, I remember reading somewhere that class
loading from jars
was faster than class loading from a class in the file
system, and that
loading from uncompressed jars was also faster than
from compressed jars
(no uncompress overhead).
Now if the above is true:
- The regular jars
built with Eclipse plugins are compressed: this is
bad...
- The jarred
plugins distro made by the pde export are compressed too:
this is
double
bad...
Just my 2 cents, as those simple optimizations of the builds could
make
overall class loading faster and Eclipse zippier without getting
the
downloads bigger, as you want the downloads compressed.
BTW,
there is a slight reduction in size when you compress an
uncompressed jar
compared with having a jar whose individual entries
are compressed. Looks
like the zip algorithms are able to make some
optimizations when working on
larger uncompressed files.
So if you were to leave jars uncompressed, you
may get:
- faster class loading i.e. faster overall eclipse
- slightly
smaller compressed downloads (not a big deal)
But do not take my word
for it!
--
Cheers
Philippe
philippe ombredanne | nexB -
Open by Design (tm)
1 650 799 0949 | pombredanne at nexb.com
http://www.nexb.com
_______________________________________________
platform-core-dev
mailing
list
platform-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-core-dev