In `Script::ToJSVal<IComponent*>`, we currently do not cache the JS wrappers around C++ objects, (e.g. for such componentss such as CCmpPosition, CCmpOwnership, CCmpRangeManager, etc. This means we create objects every time we call QueryInterface. This means that all QueryInterface calls to those objects are un-necessarily slow (also, we query an std::map right now, which happens to be slow enough to show up in my profile runetc).
I think it might also be an optimisation problem to an extent in the JITThis means we create objects every time we call QueryInterface. This means that all QueryInterface calls to those objects are un-necessarily slow (also, but that's rather harder to say.we query an std::map right now, It also means we don't need to GC so much since we don't create so much garbage (would need to be measured).
My approach here is to simply hook into GetJSInstancewhich happens to be slow enough to show up in my profile run).
This is an inefficient approach, butas we might just want to do it anyways and generalise and refactor ScriptComponentdo query those components rather often.
I think it's also not great to have so many PersistentRooted because those are a std::listn general, this reduces GC pressure considerably, particularly in the Nursery, and improves performance regardless.
Furthermore, this swaps out our usage of PersistentRooted for JS::Heap. This has good performance implications, see https://code.wildfiregames.com/D5004#213715 for details.
Overall, but that's a story for a different daythis results in faster JS-C++ interop.
I think this is a 1-5% performance improvement over a typical sim update, as reported by a dumb replay on Combat demo (not the huge version but a modified regular version).Proper profiling results coming soon™