Re: Help Needed

Federico Mena Quintero wrote:
On Wed, 2006-08-16 at 15:39 +0530, Kaustubh Atrawalkar wrote:

I am working on glib optimization for our product. I just need to know what is the use of G_QUARK_BLOCK_SIZE (defined in gdataset.c) and used while allocating memory for any types? Also why we need the size 512 bytes for that quark block? Cant we reduce them to say 64 bytes or somewhat like that. We have very critical memory requirement. So need so save as much memory as possible. If you can give me some more hot spots where i can save more memory it will be very helpful to me.

Quarks are stored as an array which maps quark IDs to strings, and in a
hash table which maps strings to quark IDs.

When you register a new quark, you may need to grow the array of quark
IDs.  G_QUARK_BLOCK_SIZE is simply the number of quarks that can be
registered before the array needs to be re-grown.  This is the code from
the internal g_quark_new():

  if (g_quark_seq_id % G_QUARK_BLOCK_SIZE == 0)
    g_quarks = g_renew (gchar*, g_quarks, g_quark_seq_id + G_QUARK_BLOCK_SIZE);
  quark = g_quark_seq_id++;
  g_quarks[quark] = string;
  g_hash_table_insert (g_quark_ht, string, GUINT_TO_POINTER (quark));

You can certainly make that number smaller.  Remember that on average
half of G_QUARK_BLOCK_SIZE will be "wasted space" from the unused
entries at the end of the array. On a 32-bit machine, this would be 512 * sizeof (gpointer) / 2 = just 1 KB per process. That's probably
too small a value to optimize for, unless you have *really* tight

Yes we have *really* tight constraints. One more thing about the slab allocator. As per my study the slab allocator uses POSIX_MEMALIGN to allocate blocks of memory at a time though only small amount of that is used at that time. This chunk size can be set and can be disabled through G_SLICE environment variable. My requirement of memory is at the most 2Mb (means the apps wont exceed this limit) then can removing the slab allocator will help me ? I can see the noticeable change in small apps (less than aroung 300/400k) but not in large apps. Comment plz.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]