Florian Weimer <Florian(_dot_)Weimer(_at_)RUS(_dot_)Uni-Stuttgart(_dot_)DE>
writes:
"Michael Young" <mwy-opgp97(_at_)the-youngs(_dot_)org> writes:
Derek Atkins asked:
Have you looked into why it is faster?
A partial-body encoding requires a power-of-two sized buffer be
repeatedly filled (completely, or until end-of-input), and then copied
to the output stream. An indeterminate encoding has no length
information whatsoever, and so requires no buffering or copying.
In conjunction with compression, the claim that this affects
performance is a bit peculiar because compression itself typically
requires such buffering, and adds much more overhead anyway.
That was my impression as well. Considering that most modern Unix
systems have some amount of buffering ANYWAYS in the I/O system, I
can't see how doing extra buffering really affects anything. It's not
like you can really do a copy-in-place because you need to prepend
PGP-packet headers before the transformed data. And, as you say,
compression has to buffer data anyways.
When Colin and I were first working on this back in '95, we _did_
buffer the data, and quite honestly it seemed to work just fine; much
better than writing to a file like PGP 2.x did. And yes, we'd
definitely try to reduce the number of memcpy() functions that had to
happen. But it's just as easy to encrypt-in-place as it is to
encrypt-to-a-different-buffer.
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord(_at_)MIT(_dot_)EDU PGP key available