www.satn.org
ASCII vs. Binary



Reaction to a ZDNet article complaining that ASCII protocols take up more space than binary. [David Reed, 2002-01-09]

asciivsbinary.htm

                                                                 Connectivity: What it is and why it is so important >

Fat Protocols are clogging the Net! (ASCII polluters beware!)

According to this ZDNet guy, binary protocols are smaller and faster than ASCII, and binary protocols are more secure, because ASCII gets sent in "plaintext" (whereas I guess binary gets sent in "plainbinary" which is super-secure). So I thought for more than 5 seconds about whether I believed this, and came up with:

Once upon a time I compared the average sizes of binary compiled programs and their source code in C, since the size of the binaries would presumably be highly compressed and efficient. If you stripped comments, the source code was on the average about 1/2 the size of the binary code - though of course it executes slower. YMMV, but no way was the source code enormously bigger. And as far as data is concerned, the number "10" takes a wasteful 16 bits to store, but the binary version takes an efficient 4 bytes.

And then you can try comparing the size of ASCII PostScript files for an interesting image with the "efficient" codings like GIF for the same thing.

Examining the protocols in common use that are not ASCII-based, I would say that fixed field sizes use up quite a bit of space.

The clueless lead the blind.

There is a real reason why we need faster networks for "web services", but it isn't data size - it's latency. If you have computers talking back and forth a lot to process a request, you need to reduce the delay. You're not gonna get that by encoding in binary. You're gonna get that by making the pipes fatter so an individual packet gets there faster and so the pipes are emptier, reducing queuing delay as networks get congested.

- David Reed, 2002-01-09

Essays  About                    Next >
© Copyright 2002, 2003 by Daniel Bricklin, Bob Frankston, and David P. Reed
All Rights Reserved.