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: Idea - NDYNAMIC, __sfmoreglue()

On Sat, Apr 20, 2013 at 7:16 PM, Freddie Chopin <> wrote:
> Hello!
> Currently when opening files the FILE objects are stored in reent struct in
> "glue" structs. Whenever more space is needed __sfmoreglue() is called to
> allocate space for NDYNAMIC number of FILE objects. Currently NDYNAMIC is 4.
> The FILE is a little over 100 bytes, while struct _glue is 12 bytes.
> On embedded targets (like small microcontrollers) you usually don't need a
> lot of files (if you need any...), so if you - for example - wish to use
> only one, you end up allocating space for 4, thus ~300 bytes are wasted.
> So I've come to an idea to reduce NDYNAMIC to 1 and possibly rework _glue
> struct to HAVE the FILE object and just one pointer (so only 4 bytes
> overhead) - effectively like a singly-linked list. If we disregard malloc's
> overhead this solution would use just 4 bytes more (in case of 4 FILE
> objects):
> currently - 4 * sizeof(FILE) + sizeof(_glue) [which is 12]
> proposed - 4 * (sizeof(FILE) + sizeof(pointer))
> From mallocr.c I gather that malloc overhead is just 4 bytes (+ some
> optional alignment overhead), so if you actually need 4 FILE objects, the
> proposed solution would use ~16 bytes more. In case the number of files is
> not divisible by 4 the gain is significant.
> Do you think it makes sense? Should such a thing be conditional (maybe on
> some configure option) or for everyone?

Maybe a configuration options to allow end user to choose how many
FILEs are allocated each time? Or just redefine NDYNAMIC in your

Best Regards.

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