Re: Speed difference in Gnus: a step in the right direction
Stephen J. Turnbull wrote:
>>>>>"sjt" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
>>>>>
>>>>>
sjt> For example, here's the output of (extents-at (point)) in a Gnus
sjt> summary buffer:
sjt> (#<extent (1, 10542) D paste-function text-prop 0xa062cec> ;;
Uh-oh....
The presence of this monster extent is due to Gnus's abuse of text
properties as a "portable" way to unify overlays and text properties
across Emacsen. As usual, Gnus abuses turn out to be a great way to
find XEmacs bugs, though!
What happens is that because text properties coalesce, some property
that is applied to every line in the summary buffer ends up swallowing
the whole buffer. The text property in question is 'start-open, and
the value is t. (This is badly broken, since 'start-open is not a
property of the text, but of the extent itself; it cannot usefully be
a text property since extents carry only one text property. Ie, what
we have here is an extent whose only purpose is to announce that it
itself is start-open.)
i think gnus is trying to do the equivalent of setting the
`front-sticky' and `rear-sticky' properties. one of the things i tried
to do in my new text-property implementation is implement these
properties directly.
GNUS HACKERS TAKE NOTE: The function
`gnus-xmas-extent-start-open'
maps over the extents near some arbitrary buffer position; I'm not
sure from Ben's descriptions whether this is an operation that is
affected by large extents.
yes, i think so. if i remember aright, the problem is in updating the
soe cache, which lists all extents overlapping some specific position.
map_extents() definitely uses the soe, and moves it appropriately as it
maps. (unless you give it some flag like `start-in-region' or
`end-in-region', which makes life easier; or unless you define the
constant DONT_USE_SOE [for debugging purposes only!], in which case it
just brute-forces things by starting from the beginning of the buffer.)
ben