Josiah Carlson:
In this rewriting, I was going to ask you if you would consider
a patch that changed the underlying structure of data representation.
Say, for example, that instead of arrays of characters, with a
linebuffer that is really just an array of positions, there were to
exist blocks of characters. Say 4k of data each block, each of which
include some number of full lines (a function of the lengths of lines)
(with pointers). Each one of these blocks would link to adjacent blocks
as a doubly linked list (for quick and easy scrolling over time, fast
sequential access, etc.), as well as a tree hierarchy laid over the top
of it for log-time access to arbitrary blocks/lines. Internally, each
node in this tree could hold certain information about the range of
blocks that descend from it:
Lines can be longer than 4K. This increases individual character
access time which is currently a single test and index to require
looping. You'll have some messy buffer operations (line in middle gets
too long so last line needs to pop off into next (potentially new)
block, ...) and there'll be wasted space in each block which will grow
over time as text jostles around (or you pay the cost of occasional
compaction). Maybe it would be a win but its not obvious to me and I'd
want some convincing benchmarks. The line starts array is a bit of a
weakness in the existing code but Partitioning from SinkWorld is a
faster version of that which could be inserted into Scintilla fairly
painlessly.
number of lines
number of 'virtual' lines (when wrapping is enabled)
This is view state so doesn't really belong in the document unless
you want a set of virtual lines matching each of the views.
maximum length of these lines
In what sense? Pixel/display with is also view based.
Neil
_______________________________________________
Scintilla-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scintilla-interest
