[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] p2 repository optimization
- From: "Tom Huybrechts" <tom.huybrechts@xxxxxxxxx>
- Date: Thu, 14 Feb 2008 23:50:47 +0100
- Delivered-to: email@example.com
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=vNRO7zgy1hcUz4DyJi7xYbDhg9jvBEGZgr1z4Fo1T7tJpMIJXtEhzR9JZPjiDWags4n5HviMabelhKbn3bgPXgNeuNHKUDSiX8eFhHgd2k0ahyxHVsHUATWqilYw0vz86y5CCBnK964IWLqPHwWyum5NmPUguJcfObcO1n4Xh5I=
> > 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.