Guillem Jover wrote: > But even then I think > I'd just prefer switching the code to use chunked I/O instead, which > should be as reliable, and use consistently way less memory at any > given time.
Hmm, that basically means reverting commit 864e230e, since stdio uses chunked I/O internally. It would be interesting to try to figure out where the time went there: . function call overhead for getc/varbufaddc loops . memory management when the field and value needed to grow . copying from I/O buffer to field/value buffers . locking for each getc call Any tips for profiling this? I would think the time spent here is likely to be negligible in a typical dpkg run; ‘dselect update’ would be the main place this matters. Jonathan -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100526023205.ga1...@progeny.tock
