Re: Preparing a new draft...

[Derek Atkins <warlord@xxxxxxx>]

Florian Weimer <Florian.Weimer@xxxxxxxxxxxxxxxxxxxx> writes:

> "Michael Young" <mwy-opgp97@xxxxxxxxxxxxxx> 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@xxxxxxx                        PGP key available