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 >
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4