Core: QUnit.equiv inner refactors [Step 1] #1700
Can you elaborate what you mean by this? I understand ES Module cache as being about files executed via
I do note as reminder that these are (currently) inlined and compiled to ES5, which may or may not affect the outcome. Perhaps you're measuring this at the distribution layer, e.g. importing the qunit.js artefact and noticing an improvement there by letting it compile these upfront instead of lazily. To my knowledge, JS engines nowadays defer compilation of declared functions until they first run, but that they have special awareness of the IIFE paradigm and eagerly compile those during the top-level file compilation e.g. not re-entering the compiler when the top-level executes the
If I understand correctly, this is intended to improve startup time for the script, not runtime for diff operations, correct?
Ack. If the values are strings only, you can use a StringSet shim that uses native Set when available. I added a StringMap for this as well in src/globals.js. I have a 3-line StringSet implementation in MediaWiki that you're welcome to add here.
Node.js stores/caches module exports as an object to avoid extra filesystem calls. In node.js commonjs imports, this is under
Here is how for example I circumvent the module cache by using a querystring on an imported file that has its contents changed, only way I could make node.js not use the cache of the
There is probably no performance benefit compared to IIFE as the cost of calling additional function here is negligible but I think its still better to have the code/functions more flat, and always return the module object directly instead of doing the computation/mutation on an import.
👍 I'll add this to
Small refactors (removals/adjustments) to make code more readable. Makes code more readable and remove variable mutations. * Remove IIFE closure, moving main function as direct export, and the rest as top-level local function. * callbacks.object: Optimize compareConstructors(). * callbacks.object: Optimize object comparison prop call by skipping overhead and indirection of typeEquiv() for known array type. * callbacks.array: Optimize isContainer() away, using a predefined Set. * innerEquiv: Remove array allocation by re-using `slice` reference. Closes #1700.
I kicked off a browserstack-full run in CI, and noticed that IE11 failed due to an infinite loop.
I narrowed this down to the fact that native
…rted Avoid IE11 failure, where we otherwise fail to do proper recursion checks against cyclical JSON. Ref #1700 (comment)
As part of #1700, there was an inintended change to how we compare constructors. Instead of comparing `obj.constructor` of the actual value, we started comparing the constructor property as it exists on the prototype before the constructor function runs, and thus also before any after-the-fact mutation to an object property. Undo that part of the change and add a regression test. Fixes #1706.