Re: optimal way to use Memory Chunks

[Gus Koppel <gtk spamkiller bytechase cx>]

Olivier Sessink wrote:

> Gus Koppel wrote:
> > 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..

If it's not treated in a rather special way I suppose your Undo history
to be just a LiFo stack with elements of identical size. For this I
would simply use dynamically allocated arrays of your Undo step objects,
one array per document, indeed. GLib provides GArrays for this purpose,
but I wouldn't use them either.

The simpliest way is to define (and unconditionally allocate) a fixed
maximum number of elements, i.e. 5000, per document. The smarter way is
to provide three functions (due to simplicity could even be macros) like
undo_stack_push(), undo_stack_pop() and undo_stack_moveto().

undo_stack_push() would add one element to the stack and resize
(enlarge) the stack by a fixed number of elements, i.e. 256, if
necessary. undo_stack_moveto() would move the stack pointer to any
already allocated element within the stack. undo_stack_pop() would
simply invoke undo_stack_moveto() to move the stack pointer one element
back. An optional undo_stack_cleanup(), to be invoked occasionally,
could shrink or deallocate the stack space if there are far less
elements in the stack than it has capacity for.

My point is: for a LiFo stack of equally sixed elements GMemChunk isn't
an appropriate feature. If at all, then GArray would better serve this
purpose. But I would consider even that one overhead. Those simple three
or four custom functions described above would do the job better, more
efficiently and without any overhead of GMemChunk or GArray. You would
always have to invest some extra typing to put a GArray into the context
of your program, your objects, etc. This could be saved by a direct,
custom implementation.

In general, I think GLib features should not be utilized by all means.
If a custom implementation is that easy (like this one appears to be)
and likely more efficient, then you shouldn't use toolkit functions just
because they are there and could solve the problem as well. Too much
ardour for that might let some people end up one terrible day by writing
x = g_math_add (g_math_sub (a, g_math_mul (b, c)), d);
instead of just
x = a - b * c + d;