"Neil Hodgson" <[EMAIL PROTECTED]> wrote: > > 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.
I do think that it would be possible to make it faster, but point taken... Step 1: add 0,1,2,4 byte styling options. Step 2: think about trying to make Scintilla faster (and/or provide 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. This was all based on my answer to my own question of "If we could make Scintilla faster in the operations for which it is slow (and perhaps slightly slower in the operations in which it is fast), what would it take?" Currently, Scintilla has some issues when dealing with wrapped lines, huge documents, etc. The chunking of data, caching line information, and other things were meant to attempt to deal with such things. Aside from learning more about CellBuffer as I go along, my knowledge of Scintilla, in general, is very limited, so if you say it's not applicable, so be it, consider it withdrawn as a proposal. - Josiah _______________________________________________ Scintilla-interest mailing list [email protected] http://mailman.lyra.org/mailman/listinfo/scintilla-interest
