Re: SFL performance problem with encryption and decryption of large messages

> The aim of the rounding up was to ensure that most of the realloc() calls to
> add an extra 8 bytes were to the existing size, and effectively a no-op,
> which the runtime library optimises to do nothing.  The figures I chose were
> an arbitrary compromise between performance and memory wastage.

This technique improves performance, but it only works until your buffer
size is around half of your physical memory (or worse, any per-process
physical memory limits). After that, the two memory buffers don't fit in
core memory simultaneously, and each additional alloc/copy operation
writes *both* buffers to disk and then reads them back again (via the
paging system of your operating system). *That* will degrade
performance...

A better answer is to use build a chain of medium size memory blocks,
and then copy those blocks back into a single memory buffer at the end
of the encryption operation. If I recall correctly this is very easy to
do with an STL deque, for example.

Unfortunately, that's a harder code patch, so you might be stuck with
the limitation.

-- 
Harald Koch     <[email protected]>

"It takes a child to raze a village."
		-Michael T. Fry