[PATCH newlib]New configuration option disable io vector buffer in Newlib

[Freddie Chopin]

W dniu 2013-03-27 08:33, Bin Cheng pisze:
> Thanks for suggestions. As for the changes:
> For code size, this patch reduces about 2+KB text section with below command
> line for a simple formatted IO program:
> $ arm-none-eabi-gcc -mthumb -mcpu=cortex-m0 -Os -ffcuntion-sections
> -fdata-sections -Wl,--gc-sections -lc -lnosys -lc main.c -o main.exe
>
> The library itself is build with "-Os -ffunction-sections -fdata-sections".
>
> For performance, I measured a formatted IO test which calls lots of
> "snprintf" and runs for about 10Secs. Turns out this patch can improve
> performance about 5~6%, but I won't claim how good the patch is because it's
> just one use-case.
>
> As for how-to document, I am not sure how to handle it. There are a bunch of
> "--disable/enable-*" options, but neither HOWTO nor README mentions them.
> Maybe we could re-factor the document and find a place to describe these
> options in detail.
>
> Thanks.

Great to see some code/speed reduction, but - on the other hand - what 
is LOST when this new option is enabled? I mean - all these uio, iov 
structs are there for some reason, they have some purpose, removing them 
probably limits something etc. Or maybe the change just moves the things 
done directly on __suio and __siov structs "out" (simplifying some code 
path) and that's all?

BTW - lately I've thought about a big possibility of reducing RAM usage 
of newlib when using reent-small. Currently when doing something on FILE 
a space for 4 FILE structs is requested and added to "glue", so if you 
need 1 or 5 files, the other 3 are wasted (1 FILE is a little over 
100B). Would changing the allocation multiplier (NDYNAMIC or sth like 
that) from 4 to 1 be a very stupid idea? I know that malloc has 
overhead, but 8 (4?) bytes per 100+ byte struct is a lot less than 1, 2 
or 3 such 100+ byte structs laying around useless. As such low 
"threshold" makes sense only for low-end platforms, maybe having that as 
a configurable parameter (just like default size of stdio buffer) be a 
good idea, so that toolchains for ARM microcontrollers could use 1, and 
Linux could use 4? I believe that such change would make reent-small a 
nice option, as once I've heard (from you or was that someone else of 
the GNU ARM toolchain team?) that reent-small uses too much RAM to be 
considered for small memory devices (reent-not-small needs only 3 FILE 
structs and usually you don't use them on an MCU anyway).

4\/3!!