[Python-Dev] Memory management in the AST parser & compiler

[Michael Walter]

The behavior of libiberty's alloca() replacement might be interesting as well:

http://gcc.gnu.org/onlinedocs/libiberty/Functions.html#index-alloca-59

Regards,
Michael

On 11/18/05, Alex Martelli <aleaxit at gmail.com> wrote:
>
> On Nov 17, 2005, at 5:00 PM, Thomas Lee wrote:
>
> > Portability may also be an issue to take into consideration:
>
> Of course -- but so is anno domini... the eskimo.com FAQ is (C) 1995,
> and the neohapsis.com page just points to the eskimo.com one:
>
> > http://www.eskimo.com/~scs/C-faq/q7.32.html
> > http://archives.neohapsis.com/archives/postfix/2001-05/1305.html
>
> In 2006, I'm not sure the need to avoid alloca is anywhere as
> strong.  Sure, it could be wrapped into a LOCALLOC macro (with a
> companion LOCFREE one), the macro expanding to alloca/nothing on
> systems which do have alloca and to malloc/free elsewhere -- this
> would keep the sources just as cluttered, but still speed things up
> where feasible.  E.g., on my iBook, a silly benchmark just freeing
> and allocating 80,000 hunks of 1000 bytes takes 13ms with alloca, 57
> without...
>
>
> Alex
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/michael.walter%40gmail.com
>