The system tray still has problems. See the screenshot attached. Besides, using g_slice API won't cause any problem since the pointer is both allocated and freed in the same place. So, there is no reason not to use it although this won't cause visible performance gain.
On Sat, Jul 11, 2009 at 1:32 AM, Marty Jack<[email protected]> 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. > > Jürgen Hötzel wrote: >> On Wed, Jul 08, 2009 at 05:48:05PM -0400, Marty Jack wrote: >>> There is no good reason to use different memory allocation API in >>> different parts of the code. The memory usage is not demanding >>> enough to require special treatment. There is too much risk of >>> allocating with one API and freeing with another. >> >> of course memory allocated by g_slice* must not be freed using g_free >> and vice verse. >> >>> The slice calls were only used in one or two places. >> >> Which is a bad thing. The whole glib object/type system uses slice >> allocation already. >> >> Application code should also use slice allocation so we can leverage >> the performance improvements over g_malloc. g_slice_alloc will always >> use the best allocator. Only if you have to re-size allocated memory >> you must fallback to g_malloc. >> >> 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
