Re: Text Widget issues (forked from: Possible Glib BTree substitute)

[Derek Simkowiak <dereks kd-dev com>]

> For a 50,000-line buffer, [...]
>  - 6.5 megs of char data
>  - 2.4 megs of toggle segments
>  - 1 meg of wrapped line structs
>  - .47 megs of tag summary information
>  - .28 megs of nodes
>  - .24 megs of pixmap segments
>  - .12 megs of node data

	I had no idea the toggle segments would use so much ram.  It's the
largest non-character memory hog, by an order of magnitude.  But at 8
bytes per on or off toggle:

typedef struct TkTextToggle {
    struct TkTextTag *tagPtr;           /* Tag that starts or ends here. */
    int inNodeCounts;                   /* 1 means this toggle has been
                                         * accounted for in node toggle  
                                         * counts; 0 means it hasn't, yet. */
} TkTextToggle;
 
	...I can see how it would add it up.

	(All of the following is subject to change:)

	I'm designing my tag system to be slightly different from the
TkText design.  To begin with, I'm dropping the 'priority' system for
tags.  I find it confusing, and I don't see the point.  Rather, I'm going
to have simple on/off toggles.

	Next, I'm not going to track particular off tags for TkTextTags.
Instead, I'm going to have generic "close" tags, which will always apply
to the nearest unclosed on tag.  I.e., my tags will render exactly the
same way Netscape would render

This <font color="ff0000">is my <font color="00ff00">line</font> of
text</font>.

	Notice that there is only a generic </font> tag.  I think people
are more used to a system like this than they are a priority-based system.  
My widget's "Tags" will simply have more than just the color attribute.

	The way I plan on tracking toggles is practically the same as the
TkText: I'll have a linked list of unmatched toggles at every parent
node.

	This means my toggle can be as small as 

typedef struct TextToggle {
    struct TkTextTag *tagPtr;           /* Tag that starts or ends here. */
} TextToggle;

	...where a tagPtr == NULL means this is a close tag.  That would
immediately cut the toggle memory usage in half.

	Another option is to have a hardcoded maximum of 255 different
"styles" in a particular text buffer.  Then, I could use an int from
0..255 as a key to the Tag.  That would mean:

typedef struct TextToggle {
    guint8 tagIndex;           /* Tag key that starts or ends here. */
} TextToggle;

	...where tagIndex == 0 means a close tag.  That would reduce the
toggle memory usage by 7/8, at the expense of flexibility.  Comments on
whether or not a 255 style limit is too restrictive are desired (for
syntax highlighting it certainly is not).

	Another idea I'm playing with is to make every line have only one
text buffer--perhaps even a gapped text buffer.  That would mean only one
char data pointer per line, as though it were unmarked text.  I could
then use some sort of GtkText-like indexing system for the Tags.  I
haven't thought this through yet.

> Also remember that memprof is showing the allocated memory, but not
> the overhead from malloc() itself, which can be reduced by using fewer
> allocations for the same data.

	Would using GAllocator for that be appropriate?


--Derek