Re: About IDL's string enums

These strings are English words, right? Most of which are fewer than 8 characters and can therefore fit in a 64-bit register?

JavaScriptCore turns JS string literals into AtomicStrings at parse time, which means they can be compared for equality in a single instruction. The performance problem you mention is an implementation detail of V8, and would best be fixed by improving V8, rather than forcing every Web developer to learn a new style of API.

You mentioned “critical path of the API (e.g. draw call).” Two out of the 3 platform APIs use draw calls which don’t accept any enums, and the remaining API only accepts a single enum. Indeed, even in WebGPU's sketch API, our own draw calls don’t accept any enums. Other calls which accept enums are used to compile device-specific state, which is already a super expensive operation.

There is, however, large benefit to being consistent with the rest of the Web Platform’s conventions. We shouldn’t be diverging from the existing best practices until we have concrete evidence describing what the performance benefit would be. (Premature optimization is the root of all evil.)

> On Feb 26, 2018, at 5:45 PM, Kai Ninomiya <kainino@google.com> wrote:
> 
> Hey folks,
> 
> I had a brief chat with Brad Nelson (cc'd) (WASM chair) last week about string enums. Here's my summary (Brad: if you wouldn't mind, correct me if I've misrepresented anything).
> 
> * Probably possible (though difficult) to make them somewhat fast (~as fast as JS is now), and likely to be valuable for other Web APIs too.
> * BUT: it may be hard to make them fast enough to rely on them in the critical path of the API (e.g. draw call). I investigated this a bit more:
> 
> Taking a look at Blink code for some APIs that use IDL enums (like WebAudio and 2D Canvas), I determined, at least, that these entry points are not doing anything special when they take in IDL enums: They just receive a C++ string object, and convert to a C++ enum via a helper function that does string comparisons.
> (It's possible that string enum comparisons are fast in JITed JS (e.g. webapi.getThing() == "variant2"), but they are not currently fast going out to native code.)
> 
> If I'm understanding correctly, solving this problem (just for JS) would require a whole new concept to be added throughout the stack - from the JS engine (V8) API to the bindings code to Blink - to be able to recompile string enums from the app's JS source into some kind of integer ID that can be compared efficiently in Blink. (Blink would have to be able to query this integer ID from the V8 VM as well.)
> 
> And that's ignoring WebAssembly. For WebAssembly, we would need some way for it to - at load time - either (a) like Blink, query the integer ID for a given string, or (b) create a table from i32s to strings which, when used in Host Bindings, are guaranteed to get efficiently turned into the integer IDs on the way into Blink.
> 
> All in all, this looks like a huge project, and I definitely feel we cannot rely on it when designing an API for WebGPU (all assuming I'm not missing something important).