This is the mail archive of the mailing list for the newlib project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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.


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).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]