I've had a problem with TextMate (and with OmniOutliner), where writing in very long lines was extremely slow. Very slow.
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.
It might be a coincidence, but then maybe not.
/Peder Axensten
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
On 3. Nov 2006, at 21:12, Alaric Snell-Pym wrote:
[...] 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.
There are at least 3 things which can significantly affect typing speed:
1) text rendering -- this is *horrible* slow for long lines, the black box structure of the APIs I am using makes it difficult to ask for rendering just a subset of the line, but I am placing good money on CoreText for Leopard. A test for this problem is to enable soft wrap.
2) spell checking -- the system spell checker can be very slow with misspelled words, and I pass the full line to the spell checker each time the line changes. A test for this is to disable spelling as you type: I think part of the problem is that if there is a misspelled word, the spelling server then checks all dictionaries for that word, so misspelled words result in much worse performance out of the spell checker than correctly spelled words
3) folding patterns -- when you edit a line, it is checked against the folding patterns for the current language grammar. These are regular expressions, and if crafted in an unfortunate way, they can have exponential time complexity. We have fixed a few of such cases, mostly it can be fixed by just changing the pattern.
Of course there could also be a problem with the actual language grammar parser, as this one is also based o regular expressions.
To test the latter thing, change the language (but as that can change preferences for #1 and #2, check those first).
-
Alaric Snell-Pym -
Allan Odgaard -
Peder Axensten