api_lib.c MEMP_API_MSG usage

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

api_lib.c MEMP_API_MSG usage

Goldschmidt Simon
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
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: api_lib.c MEMP_API_MSG usage

Andreas Becker
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
> [hidden email]
> 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
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users