B0;243;0cOn Fri, Jul 10, 2009 at 01:32:21PM -0400, Marty Jack wrote: > I have no particular objection to changing over at some point when > things are quiet. However in thirty years I have seen plenty of > cases where people spend a lot of effort to optimize something that > makes no performance difference at all.
What I meant to say is: g_malloc is some kind of "low level function" that should not be used directly. The optimization effort is done by g_slice as it chooses the best allocation mechanism. So there is no overhead in LXDE code. Maybe it's not worth porting existing code (besides clean code: single API usage) because there is no noticeable performance benefit. But for new code (quote from glib manual): The slice allocator can allocate blocks as small as two pointers, and unlike malloc(), it does not reserve extra space per block. For large block sizes, g_slice_new() and g_slice_alloc() will automatically delegate to the system malloc() implementation. For newly written code it is recommended to use the new g_slice API instead of g_malloc() and friends, as long as objects are not resized during their lifetime and the object size used at allocation time is still available when freeing. Jürgen ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ Lxde-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lxde-list
