It depends what you mean by "done line by line." Most of the output of an LZW compression is a string of 12-bit codes that capture the input, but there are also one or more 4096-entry tables that tell what the codes are. The early codes in the table just encode single ASCII characters, but later codes are used for discovered ASCII strings and, most important, discovered strings of earlier codes. That compression-of-compression is where its power comes from. The earlier you force LZW to wrap things up and generate the code table, the more opportunities for compression are lost. So you can feed data into LZW line by line, but it's a bad idea to force it to give you output until you need the output.
One way to think about this is that compression algorithms try to provide shortest-possible encodings of data blocks. If the data are truly random, then the data are their own shortest-possible encoding (that's the definition of random). The more non-randomness can be found (for example, non-random digrams & trigrams in natural-language text), the shorter the description can be. It's fine to know what the non-randomness is in advance (for example, the shortest description of a million-byte all-zero file is "this is a million zeroes"), but LZW does not prejudge what it will see, so it will look at English text and (without knowing it's English) encode digrams as it finds them (["th"], ["e "]), then bigger sequences ([["th"]["e "]], [" can be"], and so on.
These examples show why the only informative tests of compression algorithms use real data. If a compression routine were written with the idea that it might be especially likely to see long sequences of the same character repeated, then it might take special steps to handle that situation efficiently, and if that is what your data are like, then that routine might be best for you. In an earlier post, I mentioned the interesting case of movies, where a frame can often be best described by just listing the (few) ways in which it differs from the previous one.
