mirrors/jgit - jgit - source @ dussan.org

2993 Commity

49 Gałęzie

Gałąź: stable-3.3

Wykres commitów

Autor	SHA1	Wiadomość	Data
Shawn O. Pearce	f93a6a7229	Compress large /info/refs responses on HTTP Enable streaming compression for any response that is bigger than the 32 KiB buffer used by SmartOutputStream. This is useful on the info/refs file which can have many branches and tags listed, and is often bigger than 32 KiB, but also compresses by at least 50%. Disable streaming compression on large git-upload-pack responses, as these are usually highly compressed Git pack data. Trying to compress these with gzip will only waste CPU time and additional transfer space with the gzip wrapper. Small git-upload-pack data is usually text based negotiation responses and can be squeezed smaller with a little bit of CPU usage. Change-Id: Ia13e63ed334f594d5e1ab53a97240eb2e8f550e2	11 lat temu
Shawn O. Pearce	0d61707f12	Always close the GZIPOutputStream to release Deflater The stream must be closed to ensure the native resources associated with its internal Deflater instance are cleaned up early, instead of waiting for GC to identify the dead object and finialize it. Change-Id: Ic31b5df563f19404ed4682556999f4332aa61562	12 lat temu
Shawn O. Pearce	c0f093899f	http.server: Use TemporaryBuffer and compress some responses The HTTP server side code now uses the same approach that the smart HTTP client code uses when preparing a request body. The payload is streamed into a TemporaryBuffer of limited size. If the entire data fits, its compressed with gzip if the user agent supports that, and a Content-Length header is used to transmit the fixed length body to the peer. If however the data overflows the limited memory segment, its streamed uncompressed to the peer. One might initially think that larger contents which overflow the buffer should also be compressed, rather than sent raw, since they were deemed "large". But usually these larger contents are actually a pack file which has been already heavily compressed by Git specific routines. Trying to deflate that with gzip is probably going to take up more space, not less, so the compression overhead isn't worthwhile. This buffer and compress optimization helps repositories with a large number of references, as their text based advertisements compress well. For example jgit's own native repository currently requires 32,628 bytes for its full advertisement of 489 references. Most repositories have fewer references, and thus could compress their entire response in one buffer. Change-Id: I790609c9f763339e0a1db9172aa570e29af96f42 Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	14 lat temu

Autor

SHA1

Wiadomość

Data

Shawn O. Pearce

f93a6a7229

Compress large /info/refs responses on HTTP

Enable streaming compression for any response that is bigger than
the 32 KiB buffer used by SmartOutputStream. This is useful on the
info/refs file which can have many branches and tags listed, and
is often bigger than 32 KiB, but also compresses by at least 50%.

Disable streaming compression on large git-upload-pack responses,
as these are usually highly compressed Git pack data. Trying to
compress these with gzip will only waste CPU time and additional
transfer space with the gzip wrapper. Small git-upload-pack data
is usually text based negotiation responses and can be squeezed
smaller with a little bit of CPU usage.

Change-Id: Ia13e63ed334f594d5e1ab53a97240eb2e8f550e2

11 lat temu

Shawn O. Pearce

0d61707f12

Always close the GZIPOutputStream to release Deflater

The stream must be closed to ensure the native resources associated
with its internal Deflater instance are cleaned up early, instead of
waiting for GC to identify the dead object and finialize it.

Change-Id: Ic31b5df563f19404ed4682556999f4332aa61562

12 lat temu

Shawn O. Pearce

c0f093899f

http.server: Use TemporaryBuffer and compress some responses

The HTTP server side code now uses the same approach that the smart
HTTP client code uses when preparing a request body.  The payload
is streamed into a TemporaryBuffer of limited size.  If the entire
data fits, its compressed with gzip if the user agent supports that,
and a Content-Length header is used to transmit the fixed length
body to the peer.  If however the data overflows the limited memory
segment, its streamed uncompressed to the peer.

One might initially think that larger contents which overflow
the buffer should also be compressed, rather than sent raw, since
they were deemed "large".  But usually these larger contents are
actually a pack file which has been already heavily compressed by
Git specific routines.  Trying to deflate that with gzip is probably
going to take up more space, not less, so the compression overhead
isn't worthwhile.

This buffer and compress optimization helps repositories with a
large number of references, as their text based advertisements
compress well. For example jgit's own native repository currently
requires 32,628 bytes for its full advertisement of 489 references.
Most repositories have fewer references, and thus could compress
their entire response in one buffer.

Change-Id: I790609c9f763339e0a1db9172aa570e29af96f42
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

14 lat temu

3 Commity (stable-3.3)