Re: NSTextStorage -string inefficient

[Nicola Pero]

> Well ... if you use the -mutableString method instead of the -string 
> method, we could optimise the private class returned by this method to be 
> close 
> to giving the same speed as having direct access to the underlying 
> NSMutableString object.  This is more work to code, but would keep the API 
> clean/safe. I'll do that optimisation if you want.

Hmmm ... given that -string is the primitive method to read access to
characters, and that -mutableString read access is implemented in terms of
-string, I'm not sure what optimization you can use here.  Any read access
to string characters must pass through -string (the only primitive method
to read access characters for an attributed string), otherwise you can't
subclass it.  If -string is copying the string each time you call it,
that's something you can't work around.

Of course, we can override and rewrite everything for our private
GSTextStorage private cluster class to work efficiently for it, but ... of
course we'd really like the whole framework to be efficient/usable, not
just our own private cluster subclass.


> That being said ... as the MacOS-X documentation says 0(1) time ... they 
> are clearly not copying the string, so perhaps we should return our actual
> internal string.  However, I don't really like that!

Actually - it's not only the O(1) - another hint is that the old NSText
-string documentation states that for performance reason, they return the
current string backing store, without copying it, so if you need an
immutable snapshot, you need to copy it yourself! (otherwise it will
change when the text in the NSText changes)

I'm not sure why you don't like to return the internal string, presumably
because someone could be so stupid as to use -string instead of
-mutableString and then modify the returned string ?

In any case, we definitely need O(1) access to the string characters,
because if you do any real world usage of an NSAttributedString, you need
to access efficiently the characters, as well as the attributes, of the
string.  As far as I understand, NSAttributedString has methods to access
the attributes directly, and has this -string method which returns the
string so that you can access its string attributes directly.  The -string
method is actually the primitive method to access characters, and the doc
explicitly says it should allow efficient access to characters by a
constant-time implementation.

I think the O(1) time to access a character is essential for the class to
be usable.  It's absolutely basic.  Whoever did the API put accessor
methods for the string attributes, but did not put any read accessor
method for the string characters - but these accessor methods are
essential to do anything with the attributed string.  I think the idea is
that instead of trying to duplicate string read accessor methods in the
NSAttributedString API, it's simpler to give out access to the internal
string (properly wrapped perhaps), and you can just access the internal
string using the standard accessor methods.

I know this means the returned string is not an immutable snapshot of the
mutable attributed string contents, but just the current internal string,
so the caller needs to copy it (or the part of it it needs) himself if he
needs that.  We might need to update callers.  But I don't see any other
solution - copying the whole string for each read access to any string
character/range of characters is a killer - the framework is simply not
usable with such a bad performance.  I would be extremely surprised if in
a framework where, for performance reasons, you even have separate classes
for strings and mutable strings - so that strings are not copied unless
they are explicitly marked as mutable - you would copy a whole string per
each access to a string character.


> Another possible compromise would be to write an NSString subclass to 
> wrap mutable strings (such that they can't be mutated by it) and use that.
> The base library already uses such a class to handle substrings of 
> constant strings - if we made this public in the base library, NSTextStorage 
> could
> use it to return its contents in such a way that other classes couldn't
> modify them.  It would also be efficient - since it could have direct 
> access to the internals of the string. I think this is my preferred option.

Ok - this looks like a good option - I assume it would make you happy
about -string being completely safe against external modifications - and
still should be efficient enough.