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: "Bin Cheng" <bin dot cheng at arm dot com>
- To: "'Freddie Chopin'" <freddie_chopin at op dot pl>, <newlib at sourceware dot org>
- Date: Wed, 27 Mar 2013 18:56:29 +0800
- Subject: RE: [PATCH newlib]New configuration option disable io vector buffer in Newlib
- References: <002a01ce2a0a$96b77c90$c42675b0$ at firstname.lastname@example.org> <3862C5643B15B6468269546753EB2A9208493996 at BLTSXVS01 dot govsolutions dot com> <003501ce2abd$6dca67d0$495f3770$ at email@example.com> <5152C2EF dot 6090909 at op dot pl>
> -----Original Message-----
> From: firstname.lastname@example.org [mailto:email@example.com] On
> Behalf Of Freddie Chopin
> Sent: Wednesday, March 27, 2013 5:59 PM
> To: firstname.lastname@example.org
> Subject: Re: [PATCH newlib]New configuration option disable io vector
> 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
> > 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
> > 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
> when this new option is enabled? I mean - all these uio, iov structs are
> 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?
The purpose of this patch is to reduce code size, there is no claim on
performance at all. I think the patch runs slower in other scenarios.
The whole __sfvwrite_r stuff provides sophisticated support for different
kinds of output buffering, which is required by standard and necessary for
any advanced applications. For MCU program, it is possible to have this
facility removed to reduce code size. I did this patch some time ago that I
don't remember well how exactly the output buffering works with this patch,
though it does work in default scenario if I remember correctly. So, this
patch is only for MCU programs which don't play with file buffering.
I am not expertise in this, so please correct me if I was wrong.
> 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
> 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
> the allocation multiplier (NDYNAMIC or sth like
> that) from 4 to 1 be a very stupid idea? I know that malloc has overhead,
> 8 (4?) bytes per 100+ byte struct is a lot less than 1, 2 or 3 such 100+
> structs laying around useless. As such low "threshold" makes sense only
> low-end platforms, maybe having that as a configurable parameter (just
> 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
> was that someone else of the GNU ARM toolchain team?) that reent-small
> too much RAM to be considered for small memory devices (reent-not-small
> only 3 FILE structs and usually you don't use them on an MCU anyway).
Maybe you can start a new thread/patch, :). The problem I have is
reent_small involves malloc, which tries to allocate a chunk of memory
larger than it need. Such reserved memory is wasted for MCU programs that
don't call malloc.