> On Jan 13, 2020, at 19:28, Darin Adler <da...@apple.com> wrote: > >> On Jan 13, 2020, at 5:52 PM, Yusuke Suzuki <ysuz...@apple.com >> <mailto:ysuz...@apple.com>> wrote: >> >> We can purge type-encoding-string if we use Objective-C NS_DIRECT feature >> (which makes Objective-C function as C function calling convention, removing >> metadata). >> However, this does not work universally: with NS_DIRECT, Objective-C >> override does not work. This means we need to be extra-careful when using it. > > Yes, we need to be careful, but NS_DIRECT is likely to have more benefit than > just binary shrinking, and it should do even more binary shrinking than > hiding types from Objective-C. Use of NS_DIRECT will likely help performance, > sometimes in a measurable way.
Right. I guess that many parts of code requiring high-performance are already in C++ in WebKit project. But still, we should explore the places we can use NS_DIRECT, e.g. internal accessors of Objective-C classes. We could get benefit. One thing I would like to check is JSC APIs, since typical operation inside JSC APIs are very small. If one API is calling another internal objective-C methods, which are never overridden, we could get benefit by annotating these internal methods w/ NS_DIRECT. > > However, besides the risk of making something “non-overridable”, I think it’s > only available in new versions of the clang compiler. > >> So, as a simple, but effective work-around, in the above patch, we >> introduced NakedRef<T> / NakedPtr<T>. This is basically raw pointer / raw >> reference to T, with a wrapper class. >> This leverages the behavior of Objective-C compiler’s mechanism “one-level >> deep type information collection”. Since NakedRef<T> / NakedPtr<T> >> introduces one-level deep field, >> Objective-C compiler does not collect the type information of T if >> NakedPtr<T> is included in the fields / signatures, while the compiler >> collects information when T* is used. > > Very exciting. Does this cover all the cases we care about? Does come up for > types that are not references or pointers? Maybe we can pass arguments by > const reference? What about return values? Many cases are covered. Non-covered part is code passing C/C++ struct/class as values. We could shrink it if we allocate it by using std::unique_ptr / RefPtr / Ref and passing std::unique_ptr&& / RefPtr&& / Ref&& (since they are also introducing one-level nested structure). For the places using raw pointers / raw references, we can attempt to use NakedPtr<> / NakedRef<>. > >> ## Future work >> >> We would like to avoid including such types accidentally in Objective-C. We >> should introduce build-time hook script which detects such a thing. >> I uploaded the PoC script in https://bugs.webkit.org/show_bug.cgi?id=205968 >> <https://bugs.webkit.org/show_bug.cgi?id=205968>, and I’m personally >> planning to introduce such a hook into a part of build process. > > Beautiful. Well worth doing. Yeah, we should do it. While the above two patches removed toooooo large type-encoding-strings (like, one type-encoding-string took more than 100KB…), we still have many of very long type-encoding-strings (like 6KB). Removing this can reduce binary-size. And it could be nice for performance if this string is used some part of Objective-C runtime hash-table etc. (Not sure whether it happens) by avoiding including such a large string into a hash table. -Yusuke > > Thanks! > > — Darin
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
