Re: NSTextStorage subclass
Re: NSTextStorage subclass
- Subject: Re: NSTextStorage subclass
- From: Fritz Anderson <email@hidden>
- Date: Fri, 27 Jan 2006 11:42:22 -0600
This probably falls under the category of "any" advice, which is what
you asked for...
On 27 Jan 2006, at 3:05 AM, Rachel Blackman wrote:
... I have something akin to a log file (but with rich, attributed
strings) which may have a very great many lines. Many of these
lines are duplicated exactly across multiple textviews, and all of
which must be stored in a single master array for later reference.
No view will ever have replace/delete characters done on it.
Given this, having a single copy of each of the attributed strings
shared among all the appropriate views and the master list of
everything seemed more memory-efficient to me. But,
unfortunately... *points above*
Oh, gosh. It's an ancient precept of computer programming (the book I
get this from had examples in FORTRAN66 and PL/1): Make it right
before you make it efficient.
Build your text view so that it works without uniquing/interning the
storage. Then profile (using Shark or memory-management probes) to
see if what you have is actually inefficient. I know from experience
that the worst speed problem in a large log display is _not_ storage
management, but AppKit's recalculation of the text geometry every
time any text is added.
One solution to this, or pointers to one, may be found at <http://
www.manoverboard.org/~fritza/uoc/doxygen/crescat/
interface_tall_text_view.html> and related pages (warning: GPL code).
The root of the Doxygen hierarchy is at <http://www.manoverboard.org/
~fritza/uoc/doxygen/crescat/index.html>. The related download is
<http://www.manoverboard.org/~fritza/uoc/Crescat.dmg>.
-- F
--
Fritz Anderson -- http://www.manoverboard.org/
Consulting Programmer -- http://resume.manoverboard.org/
Step into Xcode, coming out late January -- http://six.manoverboard.org/
_______________________________________________
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