203463 2019-10-26 14:01:56 -0700 JSC C API unusably slow because of JSLock / Provide explicit locking API 2022-06-24 17:10:01 -0700 1 1 1 Unclassified WebKit JavaScriptCore Other Unspecified Unspecified NEW InRadar P2 Normal --- 1 radexpl webkit-unassigned ap mark.lam saam webkit-bug-importer ysuzuki oldest_to_newest 1584271 0 radexpl 2019-10-26 14:01:56 -0700 All JSC C API calls create a JSLockHolder object, which… I assume has something to do with thread safety, but I'm not sure if it's just meant to prevent concurrent JSC API calls, or if it's used internally in JSI as well. Either way, using JSC C API on a large structure (say, calling a native function from JS, passing an array with 30000 elements, and then iterating it in native code to construct platform-specific objects) is very, very slow because of this locking behavior. The locks get set up and torn down something like a hundred thousand times in my example. This is a real bottleneck when JSC is used extensively, e.g. for react-native's jsi (see https://github.com/facebook/react-native/pull/27016 as an example of this) — the vast majority of the time doing such a conversion (hundreds of ms in my 30K array example) is spent on locks. My understanding is that this problem would disappear completely if a single JSLockHandler was set up before a large operation involving using JSC, and torn down afterwards, since actual locking is skipped if there's already a lock for the current thread (https://github.com/WebKit/webkit/blob/master/Source/JavaScriptCore/runtime/JSLock.cpp#L114-L115). This seems to happen in the ObjC JSC API: https://github.com/WebKit/webkit/blob/3816a3012159e90c1b54d06d80fc4c7e6fc375df/Source/JavaScriptCore/API/JSValue.mm#L728 -- but if you want to do JS-native structure conversion not to ObjC but in C land or for C++ for very high performance on Apple platforms, no luck. But JSLockHandler API is not exposed in public Apple APIs, or any alternative (like a theoretical JSLock(ctx) JSUnlock(ctx) api). 1878128 1 webkit-bug-importer 2022-06-23 23:17:43 -0700 <rdar://problem/95833569>