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
|