On 25.11.2009 16:31, Paul Fox wrote:
carl-daniel wrote:
Reduce realloc syscall overhead for FT2232 and bitbang.
FT2232 ran realloc() for every executed command. Start with a big enough buffer and don't touch buffer size unless it needs to grow. Bitbang was slightly better: It only ran realloc() if buffer size changed. Still, the solution above improves performance and reliability.
this is fine, but i'm curious -- did you measure a performance change, or is this "by inspection"? it's never been my impression that historically realloc would be slow, unless the buffer is growing -- in which case there's no choice. and my perhaps mistaken assumption was that realloc() would usually not shrink a buffer.
AFAIK shrinking happens if allocations differ by an order of magnitude and at least >n size of bytes (I don't have n handy right now).
Given that FT2232 varies buffer sizes from 10 bytes (min) to 269 bytes (max) in continuous succession, I think at least some libraries will shrink and expand the buffer too often. If that happens, every second call to realloc will be growing the buffer. Some people are compiling flashrom against dietlibc and other small embedded libc variants, and those usually are performing tighter memory management.
Thanks for the review. While answering I noticed that I should have picked 269 instead of 260 as one of the parameters for the max() call.
Regards, Carl-Daniel