gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New ABI NSConstantString


From: Richard Frith-Macdonald
Subject: Re: New ABI NSConstantString
Date: Sun, 8 Apr 2018 10:55:42 +0100


> On 6 Apr 2018, at 11:00, David Chisnall <address@hidden> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]