GMemChunk oddities




I noticed a fairly simple performance problem with GMemChunks,
but while tracking it down, became rather puzzled with the
way they work in general.

The performance problem was that in GTK there is sometimes
a GMemChunk that switches quickly between being empty and
having one allocated atom. When the atom is allocated, the
memchunk allocates an initial area, and then frees it again
immediately when the atom is freed.

It would seem beneficial here _not_ to free that last area.


In looking at how to implement this, I found that when all
the atoms in one area are freed, the area is marked as free,
then g_mem_chunk_clean is called, which removes all atoms
in marked areas from the free list and frees the area.
(Since this is done immediately, only one area will ever
be freed in a single g_mem_chunk_clean)

But there is also code in g_mem_chunk_alloc that handles
the case when the first atom on the free list is in marked
area - which as far as I can see will never happen. 

I don't understand this code at all - it seems to pretend
to _free_ the area (not allocate it). There is also some
code to keep track of the last freed area and reuse it,
but this seems not to be invoked either.


My inclination is to:

a) Remove the suspicious code in g_mem_chunk_alloc (as it
   is never (?) invoked.

b) Change g_mem_chunk_clean to clean a specific area instead
   of all marked areas (since it only ever cleans one area
   anyways)

c) Stop marking areas. (But keep track of the number of
   completely free areas)

d) Avoid calling g_mem_chunk_clean when there is only a 
   single allocated area.


This still will have the allocate/free behavior when there
are n completely full areas and the next atom is allocated
and freed, but this should be quite rare.

It would also be possible to always clean up completely
free areas but keep track of the last freed area, and
reuse it.

This would have the tradeoffs

 +++ New allocations in the block would be sequential 
     (performance advantage?)

 --- Extra time is taken to clean the block when not necessary


I suppose I'll have to do some experiments to figure out
if I understand the code correctly. But if anybody (Peter?)
who has a grasp what was originally intended wants to comment,
I'd appreciate it.

Regards,
                                        Owen



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