Skip to main content
Jump to: navigation, search

Difference between revisions of "Equinox p2 Repository Optimization"

(Pack200 Optimization)
Line 23: Line 23:
 
When JARs change often only a few classes in them change.  The difference between two JARs can then be captured as a set of deletions, replacements and additions.  These can themselves be contained in a JAR.  That JAR is called a "delta JAR".  The delta JAR can itself be packed, signed, ... since it is just a normal JAR.
 
When JARs change often only a few classes in them change.  The difference between two JARs can then be captured as a set of deletions, replacements and additions.  These can themselves be contained in a JAR.  That JAR is called a "delta JAR".  The delta JAR can itself be packed, signed, ... since it is just a normal JAR.
  
To be implemented...
+
See the '''org.eclipse.equinox.p2.artifact.optimizers''' bundle and the application '''org.eclipse.equinox.p2.artifact.optimizers.jardeltaoptimizer'''.
  
 
== Full Delta Optimization ==
 
== Full Delta Optimization ==
In-progress...
+
While class delta optimization only works at the granularity of files, full delta optimization (also called binary delta optimization) involves computing differences between different version of an artifact at the byte level. Old and new versions of the artifact are compared, and a binary delta is created that describes the differences between them.  The small binary delta is transferred to the client, and then the new artifact is reassembled by combining the delta with the old version of the artifact.  The p2 implementation currently uses the [http://linux.softpedia.com/get/System/Archiving/JBDiff-31305.shtml JBDiff] utility for computing binary deltas.
 +
 
 +
See the '''org.eclipse.equinox.p2.artifact.optimizers''' bundle and the application '''org.eclipse.equinox.p2.artifact.optimizers.jbdiffoptimizer'''.
 +
 
  
 
[[Category:Equinox p2|Repository Optimization]]
 
[[Category:Equinox p2|Repository Optimization]]

Revision as of 15:43, 13 February 2008

p2 artifact repositories can hold many different forms of the same artifact. For example, a JAR artifact may exist as

  • a canonical (unmolested) JAR
  • a compressed JAR (assuming the original was not compressed)
  • a pack200 JAR
  • a delta relative to another version of the artifact
  • ...

This document outlines the behavior of p2 in the various scenarios and details how to populate a repository with a optimized forms of artifacts.

Pack200 Optimization

Pack200 is a standard part of Java 5. It is a rather radical compression algorithm that is class file aware. It typically results in approximately 70% smaller JARs assuming the JARs are mostly code. Pack200 has no effect on non-class files. Packed JARs can be supplied by the client populating a repository or added after the fact by running the Pack 200 repository optimizer. See the org.eclipse.equinox.p2.artifact.optimizers bundle and the application org.eclipse.equinox.p2.artifact.optimizers.pack200optimizer.

Once the repository has been optimized, any agent pointing at the repository will automatically choose to download the packed form of the artifact if the repository is not local to the agent. In the case of local repositories it is more efficient to simply copy the canonical form if available.

Note that the agent running must have the org.eclipse.equinox.p2.jarprocessor bundle installed and resolved.

Arguments:

  • -artifactRepository the URL of the repository to optimize

Class Delta Optimization

When JARs change often only a few classes in them change. The difference between two JARs can then be captured as a set of deletions, replacements and additions. These can themselves be contained in a JAR. That JAR is called a "delta JAR". The delta JAR can itself be packed, signed, ... since it is just a normal JAR.

See the org.eclipse.equinox.p2.artifact.optimizers bundle and the application org.eclipse.equinox.p2.artifact.optimizers.jardeltaoptimizer.

Full Delta Optimization

While class delta optimization only works at the granularity of files, full delta optimization (also called binary delta optimization) involves computing differences between different version of an artifact at the byte level. Old and new versions of the artifact are compared, and a binary delta is created that describes the differences between them. The small binary delta is transferred to the client, and then the new artifact is reassembled by combining the delta with the old version of the artifact. The p2 implementation currently uses the JBDiff utility for computing binary deltas.

See the org.eclipse.equinox.p2.artifact.optimizers bundle and the application org.eclipse.equinox.p2.artifact.optimizers.jbdiffoptimizer.

Back to the top