|Re: [equinox-dev] p2 repository optimization|
As I sad in my previous post picking the ´best´ variant (plain, packed,
deltaed) of an artifact depends|
on the environment, i.e. type of connection, speed and memory of client machine, etc.
Suppose having clients working with a GPRS connection (slower and probably more expensive) than
fetching compressed or deltaed artifacts makes sense.
Tom Huybrechts wrote:
> 4. It was mentioned in the reply below that "delta creation and > recreation is time and space intensive, and the client should only > download a delta in certain circumstances.." So should I expect that > even tho I have a smaller "optimized" repository that the update of > the jars will actually take longer than just updating full versions > of the jars? I don't numbers, however this will definitely happen depending on what your bandwidth to the server is. For example, when we turned on pack200 support (which requires a non trivial processing on the client), the installation of the SDK from a LAN slowed down because of the computation involved to unpack the jar on the client. However from home, things went much faster.I did some quick tests a while ago comparing using pack200 vs uncompressed jars for webstart downloads. On a busy LAN, I got about 7 MB/s for uncompressed download vs 800 KB/s for compressed download + unpacking. Tests done on a 40 Mb set of jars, with a compression ratio of 50%. YMMV but there is clearly a very big overhead for unpacking. Tom _______________________________________________ equinox-dev mailing list equinox-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/equinox-dev