[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New ABI NSConstantString
From: |
Fred Kiefer |
Subject: |
Re: New ABI NSConstantString |
Date: |
Sun, 1 Apr 2018 12:36:30 +0200 |
Am 01.04.2018 um 11:52 schrieb David Chisnall <address@hidden>:
>
> Hello the list,
>
> I have nearly finished the ELF version of the new Objective-C ABI. It is
> able to pass the same tests that the previous one did in -base, with a
> smaller binary and better reflection metadata. The last piece left is
> whether to improve NSConstantString.
>
> The new ABI includes some breaking changes, so will require a complete
> recompile. This gives us an opportunity to improve constant strings. I
> think we have three options:
>
> 1) Use the existing NSConstantString structure.
> 2) Simply adopt CFConstantString.
> 3) Do something new.
>
> I don’t think 1 is a very good idea. -base includes some horribly hacks to
> go and replace NSConstantString instances with NSString instances on
> initialisation because NSConstantString -hash requires that it be computed
> dynamically.
>
> Option 2 would simplify some Apple interoperability. It allows UTF-8 and
> UTF-16 strings (is this useful? Anyone in CJK locales want it?) but doesn’t
> really help with the hash issue.
>
> Option 3 would be to implement a structure something like:
>
> {
> id isa;
> const char *str; // UTF8 or UTF16 string
> NSUInteger hash;
> NSUInteger flags;
> }
>
> The flags would store, at a minimum:
>
> - Whether this is UTF-8 or UTF-16.
> - What hash algorithm the compiler used.
>
> If -base later decides to use a different hash algorithm, the implementation
> of -hash can then check the flags and if the compiler-provided hash is not
> the version being used, it can lazily set the hash ivar to something
> different.
>
> Another alternative is to set isa to different things for UTF8 and UTF16, so
> we can just provide NSUTF8ConstantString and NSUTF16ConstantString as
> subclasses of NSConstantString.
>
> Does anyone have any strong opinions in either direction?
Wouldn’t the most useful structure be the one we already use for GSString?
@interface GSString : NSString
{
@public
GSCharPtr _contents;
unsigned int _count;
struct {
unsigned int wide: 1; // 16-bit characters in string?
unsigned int owned: 1; // Set if the instance owns the
// _contents buffer
unsigned int unused: 2;
unsigned int hash: 28;
} _flags;
}
@end
Of course constant strings won’t require the hidden reference count that come
with all ObjC objects. But apart from that it seems to be a more useful
structure. Storing the length with the string should speed up some common
operations and 28 bit of hash should still be enough. There are even two unused
bits in the flags that could encode the specific hash function.
- New ABI NSConstantString, David Chisnall, 2018/04/01
- Re: New ABI NSConstantString,
Fred Kiefer <=
- Re: New ABI NSConstantString, David Chisnall, 2018/04/01
- Re: New ABI NSConstantString, Richard Frith-Macdonald, 2018/04/01
- Re: New ABI NSConstantString, David Chisnall, 2018/04/05
- Re: New ABI NSConstantString, Ivan Vučica, 2018/04/05
- Re: New ABI NSConstantString, David Chisnall, 2018/04/05
- Re: New ABI NSConstantString, Ivan Vučica, 2018/04/05
- Re: New ABI NSConstantString, Stefan Bidigaray, 2018/04/05
- Re: New ABI NSConstantString, David Chisnall, 2018/04/05
- Re: New ABI NSConstantString, Stefan Bidigaray, 2018/04/05
- Re: New ABI NSConstantString, David Chisnall, 2018/04/05