Gus Koppel wrote:
> Using such a feature like GMemChunk makes sense only if the size of the
> objects (atoms) isn't too small (less than about 16 bytes as a rule of
> thumb). Your atoms appear to be the smallest ones possible at all.
> GMemChunks are especially helpful for linked lists of any sort. Your
> atoms are apparently not big enough to contain such information.
hmm I must have been in some zombie state when I wrote that message. The
smallest struct has 1 pointer, 2 unsigned integers and 1 short unsigned
int, so I suppose that corresponds to 16 bytes (?)
[..]
> What sort of 4 byte information is to be stored, if I may ask? Is it to
> be referenced mainly by entry numbers (1st, 2nd, 3rd, ... atom) or by
> contents, i.e. locating atoms that contain particular values? Possibly
> for your app GMemChunks are not only inefficient but unsuitable at all.
so not 4 bytes, but anyway, what they are: they are changes in an editor
(Bluefish), to be used by the 'undo' function. Each struct has a pointer
with a buffer holding the change, a start and end position, and a state
'insert' or 'delete'.
As you can imagine, with 20 documents open, and doing heavy editing, the
number of instances may go up to 5000. They can be freed whenever some
document is closed, so the G_ALLOC_AND_FREE mode may be more
appropriate. I could associate a GMemChunk to each document so I can use
G_ALLOC_ONLY, but people often open many documents (100+), and edit only
a few of them. Having a GMemChunk prepared for each document would then
be quite some overload..
b.t.w.: I saw that GMemChunk is being deprecated in gtk-cvs, why is that?
regards,
Olivier
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
