Re: NSTextView typing speed - slowdown at top?
Re: NSTextView typing speed - slowdown at top?
- Subject: Re: NSTextView typing speed - slowdown at top?
- From: SA Dev <email@hidden>
- Date: Thu, 29 Sep 2005 07:01:54 -0400
I use NSSpellChecker's countWordsInString:language: ... it's much
quicker. That should give you at least a *little* better performance
and give you greater accuracy at recognizing actual words (as opposed
to counting blocks of numbers and such which may or may not be
desirable).
There is no 'fix' for this problem - at least none that wouldn't
require rebuilding Cocoa text system from the ground up. ;-) It's all
about shaving performance off of repetitive tasks (such as counting
words every time the text is modified).
You might also try putting your word count update code on a timer.
Every time the user types, a one-shot timer with an interval of a few
seconds is set (or reset). When it times out, it calls the
"runMyExtraStuff" to update the word count and anything else you've
got. If the user starts typing again before the timer fires, it's
reset. This way the words aren't being recounted every time a letter
is typed.
Hope this helps. If anyone else has any better advice (or
corrections to the above), feel free to add.
- SADev
On Sep 28, 2005, at 6:24 PM, Keith Blount wrote:
Thanks for your reply. That makes sense - I was
thinking in terms of redrawing, but forgot that the
layout manager does a lot of calculation way beyond
what you can see on screen. I'm not sure how to fix
it, though. My word count code does minimal work as it
is, only counting the changed text (it uses
-nextWordFromIndex: to subtract the count of words in
the affected range and then add the words created by
the newly inserted string). Things are complicated,
however, by the fact that the text view in question
manipulates any number of text storages that can be
held in other text views too.
It is certainly annoying that there is this slowdown.
Pasting the text into other programs, though, reveals
that both Nisus Writer and Mellel suffer far worse
slowdowns than my own app with the same text. You
would have to have a typing speed of 100wpm or over to
notice the slowdown, I'm guessing (given that I have
near 80wpm and don't notice it - I only notice it when
hitting random keys as fast as I can), so maybe I'll
just have to live with it.
I would be grateful for any advice if someone does
have a solution, though.
Thanks again,
Keith
--- SA Dev <email@hidden> wrote:
Keith:
You are inserting text near the beginning, which
means the text
that occurs after it must be 'shifted'. Appending to
the end is
easier because there is nothing to shift. Appending
*near* the end
means there's less to shift but some. The closer you
get to the
beginning, the more text needs to be shifted. The
more shifting
around, the more layout needs to be performed, etc.
Basically,
inserting near the beginning is more 'expensive'.
I think a more detailed technical explanation was
already
presented on this list, though the keywords to
search for are eluding
me at the moment (because I'm finding nothing). The
above may be
oversimplistic (or largely inaccurate), but any
applications using an
NSTextView will share in this problem - mine does.
- SADev
On Sep 28, 2005, at 3:51 PM, Keith Blount wrote:
Hello,
Is there any good reason why, on a long document
(1,000,000 characters), it would be much slower to
type at the top of an NSTextView than it is at the
bottom? This is what I am finding - if I insert
the
cursor and start typing towards the beginning of
my
text, there is a lag, but towards the end there is
none.
Admittedly, I am using a custom text storage that
provides a word count, but there is no reason why
this
should slow down typing at the top of the text
view
and not at the bottom (it keeps a running count by
counting only the affected sentence) - it should
either cause a slowdown throughout the whole text
or
not at all.
If anyone has any ideas, I would be very grateful.
Best regards,
Keith
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
_______________________________________________
Do not post admin requests to the list. They will
be ignored.
Cocoa-dev mailing list
(email@hidden)
Help/Unsubscribe/Update your Subscription:
40silentalcove.net
This email sent to email@hidden
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden