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 <[EMAIL PROTECTED]> 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@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/michael.walter%40gmail.com > _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
