I finally managed to finish up the new g_slice_*() allocator for GLib CVS and commit it. For most platforms, it should be a lot faster than malloc(), and on my machine it saves 20-30% in performance over allocating with mem-chunks. But most importantly, it does share equally sized chunks across a program, which mem-chunks didn’t, so they opened up several independent heaps of equally sized chunks, scattered all over the program and causing large wastage.
I would like to thank Matthias Clasen for an initial version of the magazine cache and Stefan Westerfeld for helping me with optimizing the common code paths.
- This blog is mostly about technical stuff related to my projects.My homepage has contacts and a project list.
-
Blogroll
-
Categories
-
Recent Posts
-
Recent Comments
-
Archives
- September 2009 (1)
- April 2009 (1)
- October 2008 (2)
- September 2008 (1)
- July 2008 (1)
- June 2008 (3)
- May 2008 (1)
- April 2008 (2)
- February 2008 (1)
- October 2007 (2)
- September 2007 (3)
- August 2007 (2)
- July 2007 (2)
- June 2007 (4)
- April 2007 (3)
- March 2007 (1)
- January 2007 (2)
- December 2006 (2)
- November 2006 (2)
- October 2006 (1)
- September 2006 (2)
- August 2006 (1)
- July 2006 (1)
- June 2006 (1)
- May 2006 (2)
- April 2006 (3)
- February 2006 (2)
- January 2006 (1)
- December 2005 (3)
- November 2005 (2)
- September 2005 (1)
- August 2005 (3)
- July 2005 (6)
- June 2005 (12)
2 Comments
Are there any real-world situations where this will result in a noticable performance increase? I’m thinking of things like startup/shutdown of application X, displaying a really large directory in nautilus, showing the open dialog and other actions that currently take far to long.
Those results are brilliant :) I’d guess this would be an ideal allocator to use for allocating private object data, which should see app startup time implications. Are there any plans to use this in g_object_new?