Peter Memishian wrote: > > - Allocations do not require a function call, just a few instructions > > (e.g. store pointer, adjust stack pointer etc.) > > - The code size and complexity shrinks significantly (e.g. no |free()| > > required in most situations) > > - Allocations on the stack benefit from larger page size (remember my > > patch to map the stack with 64k pages instead of 8k pages on SPARC; > > machines like UltraSPARC-1/2 and Niagara will greatly benefit from this) > > - Allocations on the stack are likely coming from memory which is > > already in the cache hieracy (e.g. L2 or L1 cache) since it was used > > previously (e.g. no cache blocks need to be shuffeled around to make > > room for "yet another temporary buffer" from heap) > > - Less heap+BSS (as done in "the great libcmd purge" for > > ksh93s_20061031) would be required for temporary storage (footprint) > > ... and these apply to alloca(3C) too. Despite the ominous text in the > manpage, it works flawlessly on Solaris (dunno about other Unices, > though). Granted, C99 VLAs are slicker, but alloca() gets the job done :-)
Yes, but the exercise for Solaris's wordexp.c is to use the C99 VLA's as "testbed" to ensure it works (well, it worked for Sun Studio 10 and the switch to Studio 11 blew-up the CTF tools... ;-( ) and then get other code to use this new feature, too. In general |alloca()| should be avoided in portable code and for perforamce reasons since some platforms implement |alloca()| via |malloc()|, rendering the idea of a quick&easy allocation from stack to /dev/null ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
