Hi Simon, i agree with you. There is no reason, to allocate the variables with memp_malloc. I looked for some multi referencing and reference counts, like we use them for pbufs. But there is nothing like that. It may speed things up.
Would you provide a patch for this? Andreas. > Hi list, > > I recently took a close look at the usage of 'struct api_msg' variables > in api_lib.c. Throughout the file, those variables are allocated using > the mem-pool MEMP_API_MSG. Surprisingly, I noticed that those variables > are always allocated at the beginning of a function (memp_malloc()) and > deallocated at the end of the same function (memp_free()). So, if the > lifetime of such a variable is only for one function, why not allocate > it on the stack? Although allocating through a pool is not that slow, > allocating on the stack is still faster (you get it 'for free' when > entering the function). Also, (on a 32-bit platform) a 'struct api_msg' > should be 24 bytes max, so this is not really too big for the stack, is > it? > I tested this by changing api_lib.c so all api_msg variables are > allocated on the stack and it works. Any one interested in this topic? > > Simon > _______________________________________________ > lwip-users mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/lwip-users -- MEng Dipl.-Ing.(FH) Andreas Becker Entwicklung dSys e.K. Soeflinger Str. 100 D-89077 Ulm Tel: +49.731.151579-1 Fax: +49.731.151579-9 web: www.dsys.de _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
