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]

Idea - NDYNAMIC, __sfmoreglue()


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?

Thx for your opinions!


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