> On 6 Apr 2018, at 11:00, David Chisnall <gnus...@theravensnest.org> wrote: > > It would probably help catch more bugs if we made use of NSString’s > class-cluster nature more in -base. I have just fixed a bug in GSString > where we were checking one object matched a particular class before > dereferencing the _flags ivar of the other. I caught this because the other > was a GSTinyString, which is almost never a valid pointer.
Possibly, but performance *is* an issue here. The NSString code was rewritten some years ago (moving away from them use of class cluster features) as a result of extensive profiling of real-world applications which were running too slow, precisely because NSString methods are very heavily used in real apps. At the time somethjing like 20% of the CPU was wasted in method dispatch overheads (the -characterAtIndex: method is one of the cluster primitives and a major culprit) but there were also performance issues due to buffer allocation and copying of internal representations. The changes made a substantial improvement in general performance as well as causing multipler orders of magnitude improvement in a few pathological cases. All that being said, when I was doing the rewrite a lot of it was making educated guesses at what would help and then benchmarking changes, and I know there were various cases where I made changes which had insignificant performance impact and (because they didn't make things worse) never got round to reverting them. There is therefore probably some scope for removing some 'optimisations' to simplify the code ... as long as we check that we only remove things that are really insignificant. Counterintuitively, the initial introduction of GSTinyString noticably slowed down some applications until the key methods were optimised, but it's now a performance benefit. _______________________________________________ Gnustep-dev mailing list Gnustepemail@example.com https://lists.gnu.org/mailman/listinfo/gnustep-dev