Sounds like premature optimization to me. You can't "save" bandwidth at the sub-packet level. It is like trying to "save" space used on files of less than a kilobyte in length -- you can do the math showing impressive theoretical gains, but other layers of your hardware/software stack process the data in chunks larger than that anyway, all your effort is for naught.
@patio11: Actually, you can save bandwidth at the sub-packet level. Ethernet is a common link layer protocol that we can examine: It has a variable length frame, and because it uses time-delimited bit-level framing, the smaller your ethernet frame the quicker it can be sent. The only real caveat to axod's article is that you often can't save on performance of intermediary systems (routers) because they tend to pre-allocate blocks of memory for packets, so no memory is saved when some packets are smaller. But your ISP doesn't meter you at the link layer anyway (or often even the IP level), so the savings as reported by the article are absolutely real in terms of bandwidth costs. (as in money)
Did you skip the bit where I said it would save mibbit 300GB/month transfer?
That's worth doing.
I can see the confusion, but you can't compare files with network. Files are allocated in chunks. So shaving off a few bytes of a file does indeed not always save you disk space.
However, if you send half as many bytes in your HTTP headers, you save that bandwidth. If you handle 600 of those HTTP requests a second, shaving every byte off that you can, is important. That's not premature optimization.
I don't think that's true. Bandwidth is typically the bottleneck, and AFAIK there's no minimum size (other than minimal headers) for HTTP, TCP, or IP protocols.
