On 3 Nov 2006, at 7:36 pm, Peder Axensten wrote:
I've had a problem with TextMate (and with OmniOutliner), where writing in very long lines was extremely slow. Very slow.
I've also found that if I have soft wrapping turned off and write such a long line that the entire normal 80-column page disappears quite far off left, then TextMate starts to become very slow to respond to keypresses.
I've just updated the utility FruitMenu, since the update claimed to fix a problem where writing in OmniOutliner was very slow. Guess what, writing speeds in both applications have dramatically improved.
I don't have FruitMenu myself, so it can't be that affecting me :-(
I just did an experiment. Opened a new file, Plain Text mode, and started typing rubbish. Got to column 480 and all was fine, but I'm sure it's been slow on much fewer columns than that in source files, so I copied the line 43 times; and I could see that each paste-and- hit-Return (I'd only copied the line, not the newline) was taking longer each time. So I went to the end of line 43 and started typing, and found I could only add characters at a reduced rate, about five per second (on my aging G3) - it wasn't just a time lag, the characters were appearing much slower than I was typing, and building up in an event queue somewhere.
But hit return to go to the start of line 44 and all is fine. It's still fine after I go past the right margin, but as soon as the window scrolls right, it abruptly slows down.
Since it depends on the scroll position, I presume this problem is with the display code, but it could be an inefficiency in the underlying text buffer data structure that the display code brings to light? I dunno.
ABS
-- Alaric Snell-Pym Work: http://www.snell-systems.co.uk/ Play: http://www.snell-pym.org.uk/alaric/ Blog: http://www.snell-pym.org.uk/?author=4