Three.js does a lot more though than just being a WebGL API wrapper (the WASM => JS calling overhead is negligable these days compared to the time spent inside WebGL).
Scenes with many Three.js Javascript objects might benefit because those cause GC overhead which simply wouldn't exist on the WASM side (where those objects would be regular C++ objects on the WASM heap - of course, if "C++17" means that memory management is mostly done with C++ (shared or unique) smart pointers, then the GC overhead may creep in again via reference counting and/or cache misses on the WASM side).
(you're right of course that most of the time there won't be much of a difference, but not because of the WASM => JS marshalling but because of the time spent inside WebGL calls, which can be shockingly high).
PS: Yeah, looking at he C++ headers, it's shared_ptr<> all the way down :( This might actually add more refcounting overhead when natively compiled than what typical Three.js code spends in JS garbage collection.
Scenes with many Three.js Javascript objects might benefit because those cause GC overhead which simply wouldn't exist on the WASM side (where those objects would be regular C++ objects on the WASM heap - of course, if "C++17" means that memory management is mostly done with C++ (shared or unique) smart pointers, then the GC overhead may creep in again via reference counting and/or cache misses on the WASM side).
(you're right of course that most of the time there won't be much of a difference, but not because of the WASM => JS marshalling but because of the time spent inside WebGL calls, which can be shockingly high).
PS: Yeah, looking at he C++ headers, it's shared_ptr<> all the way down :( This might actually add more refcounting overhead when natively compiled than what typical Three.js code spends in JS garbage collection.