Is the NSMutableString -appendString: method an effective way to create a large string?

Question

I plan to create a potentially large string by iterating over the collection and generating chunks at a time. If I just started with NSMutableString and added chunks to it many times, does it work reasonably efficiently or is it a Schlemiel Artist situation? It seems plausible to me that NSMutableString is implemented in such a way as to avoid this, but I cannot find any discussion of this in the official documentation, and I would like to be sure.

(Now, when I write this, I understand that in this case I can create NSArray strings and use -componentsJoinedByString: just as easy, but that would be nice to know anyway.)

Answer 1

Schlemiel’s situation doesn’t happen on its own, since all internal NS / CFString representations use an explicit length, like all valid implementation strings. (A slightly modified version of the CoreFoundation source type source from OS X 10.6.2 is available here .) The real question is about the distribution of overhead.

In the published code, variable line buffers grow by 50% at a time if they are not very large (at least ULONG_MAX / 3UL ), which gives O (log n) binding to redistribution for practical scenarios. Using the NSArray approach should result in a single distribution. On the other hand, if you build the string piecewise and release the pieces during your path, you may get less cache / VM.

In principle, the golden optimization rule applies: if benchmarking shows a problem (in a large but realistic dataset), try both.

Answer 2

I prefer to use the NSArray componentsJoinedByString: method compared to appendString because it gives you finer control over how the string looks with less effort.

Answer 3

I often use the NSString -stringByAppendingString: and -stringByAppendingFormat: . And sometimes the +stringWithFormat: method.

Answer 4

This is an implementation detail. If it were to be implemented using string C, then it would have a Schlemiel Painter problem, because Schlemiel must look for a null terminator in order to know where to start drawing more. If its length is declared in any way, then this problem does not exist, because Schlemiel knows how long he needs a pole, so that the pole vault to the end of the string to make more painting.

Ultimately, you cannot know this (without disassembly) and you cannot rely on the answer that remains unchanged on all updates, so you just need to have some faith that Apple infrastructure engineers know what they are doing.

It’s better to wait until something in your application is as fast as it should be, and then profile the application to find out what it is. In my experience, it almost never works slowly.

Answer 5

Usually I use appendString: when I create smaller lines or make relatively few modifications. If I create a large string, depending on how large, perhaps creating a string from NSArray filled with string elements might make sense.

Generally speaking, I will not build large strings using appendString:

Answer 6

I had a case where I had to make many calls to the NSMutableString appendString application, and I can tell you that it was HORRIFICALLY slow compared to just the NSString stringByAppendingString. Just FYI.