homepage

A series of write() calls is dog slow compared to
building-up a pool of data and then writing it in
larger batches.
The attached script demonstrates the speed-up
potential. It compares a series of GzipFile.write()
calls to an alternate approach using cStringIO.write()
calls followed by a GzipFile.write(sio.getvalue()). On
my box, there is a three-fold speed-up.

Although the script does not work as-is (missing import of "string",
typo between "frags" and "wfrags"), I can conform the 3x ratio.

This is true for all objects whose input could be concatenated.
For example with hashlib:
data = ['foobar']*100000
mdX = hashlib.sha1()
for d in data:
 mdX.update(d)
mdY = hashlib.sha1()
mdY.update("".join(data))
mdX.digest() == mdY.digest()
the second version is multiple times faster...

In the test script, simply changing 
def emit(f, data=snips):
 for datum in data:
 f.write(datum)
to 
def gemit(f, data=snips):
 datas = ''.join(data)
 f.write(datas)
improves direct gzip performance from
[1.1799781322479248, 0.50524115562438965, 0.2713780403137207]
[1.183434009552002, 0.50997591018676758, 0.26801109313964844]
[1.173914909362793, 0.51325297355651855, 0.26233196258544922]
to
[0.43065404891967773, 0.50007486343383789, 0.26698708534240723]
[0.43662095069885254, 0.49983596801757812, 0.2686460018157959]
[0.43778109550476074, 0.50057196617126465, 0.2687230110168457]
which means that you're better off letting the application handle buffering issues. Furthermore, the problem with gzip-level buffering is the choice of the default buffer size.
Time to close ?

agreed

Additionally, since issue7471 was fixed, you should be able to wrap a GzipFile in a Buffered{Reader,Writer} object for faster buffering.