Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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.

Stefan

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
  


Back to the top