This is the mail archive of the
mailing list for the newlib project.
Re: Idea - NDYNAMIC, __sfmoreglue()
- From: "Bin.Cheng" <amker dot cheng at gmail dot com>
- To: Freddie Chopin <freddie_chopin at op dot pl>
- Cc: newlib at sourceware dot org
- Date: Thu, 2 May 2013 16:11:57 +0800
- Subject: Re: Idea - NDYNAMIC, __sfmoreglue()
- References: <51727904 dot 8080306 at op dot pl>
On Sat, Apr 20, 2013 at 7:16 PM, Freddie Chopin <email@example.com> wrote:
> 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
> 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