This is the mail archive of the newlib@sourceware.org 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: Reduce stack usage of _vfiprintf_r()


On Oct 10 18:15, Freddie Chopin wrote:
> W dniu 2012-10-10 17:59, Federico Terraneo pisze:
> >first of all, am not a newlib devloper, just a regular user. I noticed
> >the exact same problem in RAM constrained ARM microcontrollers when
> >using newlib together with an RTOS that I developed. The solution I
> >found is different though, and is to apply a simple patch to newlib
> >that redefines BUFSIZ to 512 instead of 1024. That small change later
> >became part of a larger patch that can be found here:
> >http://gitorious.org/miosix-kernel/miosix-kernel/blobs/master/miosix/compiler/gcc-patches/newlib.patch
> >The relevant lines are 32--39.
> 
> Glad to hear that I'm not the only one that thinks newlib is "too big" (;
> 
> Your solution is "not good enough" - the stack is still wasted, 512
> bytes is still a lot - considering that _vfiprintf_r() with my patch
> uses about 300 bytes of stack, the 512 byte buffer almost triples
> that usage, so for me that's still too much (; I think dynamic

You can define __BUFSIZ__ to any small number for your target in
libc/include/sys/config.h.  See my other mail to this thread.

> allocation in this place is perfectly reasonable - whatever overhead
> does malloc have it's better than wasting such amount of stack in
> every situation (as proven in the first mail).

Keep in mind that we have to serve targets with size constraints as well
as targets which go for speed.  If you have a lot of output to an
unbuffered stream like stderr, calling malloc may slow down output
noticably.  I don't think calling malloc is the right thing to do in all
cases.  Maybe that's something which could be conditionalized on
__OPTIMIZE_SIZE__...

> In case of my code I
> don't expect it to be ever called, because I don't use unbuffered
> streams.

Now I'm puzzled.  If you're not using unbuffered IO, how come that
you notice a difference, given that the code in question is only
called for unbuffered IO?!?


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat


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