This is the mail archive of the
mailing list for the newlib project.
Re: [PATCH newlib]New configuration option disable io vector buffer in Newlib
- From: Freddie Chopin <freddie_chopin at op dot pl>
- To: newlib at sourceware dot org
- Date: Wed, 27 Mar 2013 10:59:11 +0100
- Subject: Re: [PATCH newlib]New configuration option disable io vector buffer in Newlib
- References: <002a01ce2a0a$96b77c90$c42675b0$ at email@example.com> <3862C5643B15B6468269546753EB2A9208493996 at BLTSXVS01 dot govsolutions dot com> <003501ce2abd$6dca67d0$495f3770$ at firstname.lastname@example.org>
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).