Core: QUnit.equiv inner refactors [Step 1] #1700

izelnakri · 2022-08-16T01:56:45Z

This makes QUnit.equiv code more readable/maintainable and probably faster due to 2 changes:

inner private functions moved to ES Module cache instead of being registered on initial IIFE call.
removal of len variable allocation for array checks.

We can also utilize JS Set and remove/inline isContainer function altogether here to do faster checks, I left this out from this PR because linter gives a warning telling me compat/compat: Set is not supported in iOS Safari 7.0-7.1, IE 9:
https://github.com/qunitjs/qunit/blob/main/src/equiv.js#L63

Also JIT compiler might be able to do further optimizations based on other small changes but unlikely.

I suggest reviewing per commit ;)

Small removals/adjustments to make the code more readable.

Krinkle · 2022-08-16T11:12:18Z

src/equiv.js

@@ -103,13 +101,12 @@ const callbacks = {
  },

  array (a, b) {
-    const len = a.length;


I believe this was meant to account for cases where length is a (custom) getter rather than a plain property or (native) array accessor. Having said that, for custom objects we shouldn't be using this function so probably fine? Just leaving here as FYI, this is not a problem.

Yes I think this shouldnt be a problem due to a typeOf here: https://github.com/qunitjs/qunit/blob/main/src/equiv.js#L282

Krinkle · 2022-08-16T11:15:33Z

src/equiv.js

@@ -298,7 +298,7 @@ function innerEquiv (a, b) {
  }

  // ...across all consecutive argument pairs
-  return arguments.length === 2 || innerEquiv.apply(this, [].slice.call(arguments, 1));
+  return arguments.length === 2 || innerEquiv.apply(this, Array.prototype.slice.call(arguments, 1));


If this is in a hot path, we may want to cache it in core/utilities like toString and hasOwn, which would also avoid the lookup through various lexical scopes to global host object, and then three property chain lookups. This is not a blocker, improvement either way.

Good idea implementing it now!

Krinkle · 2022-08-16T11:23:52Z

inner private functions moved to ES Module cache instead of being registered on initial IIFE call.

Can you elaborate what you mean by this? I understand ES Module cache as being about files executed via import statement. I'm not aware of a cache relating to local (not exported) functions declared in a JS file.

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 () part.

If I understand correctly, this is intended to improve startup time for the script, not runtime for diff operations, correct?

We can also utilize JS Set [but the] linter gives a warning

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.

izelnakri · 2022-08-16T21:45:38Z

Can you elaborate what you mean by this? I understand ES Module cache as being about files executed via import statement. I'm not aware of a cache relating to local (not exported) functions declared in a JS file.

Node.js stores/caches module exports as an object to avoid extra filesystem calls. In node.js commonjs imports, this is under require.cache[$path].exports, in ES modules, node.js returns the Module object from its internal cache and that object has the exports inside the object: https://nodejs.org/api/esm.html#commonjs-namespaces . I suspect browsers do it the same way.

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 import when the same file changes: https://github.com/izelnakri/qunitx/blob/main/lib/commands/run/tests-in-node.js#L20

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.

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.

👍 I'll add this to src/globals.js just like StringMap there in additional commit then!

Makes code more readable and removes variable mutations in compareConstructors().

Krinkle · 2022-09-11T16:21:26Z

src/globals.js

@@ -112,3 +112,25 @@ export const StringMap = typeof g.Map === 'function' &&
      });
    }
  };
+
+export const StringSet = g.Set || function (input) {


When landing, I'll change this one to a typeof ternary to match g.Map. I tend to not bother adding a type checks for most polyfills (e.g. Array or String prototype methods) as I agree that presence is sufficient. If it's set to something else, that's asking for trouble!

But, global constructors in particular are prone to conflicting with unrelated values. E.g. <h2 id="Set">Set</h2> in an HTML fixture will result in g.Set coming through the window object via WindowProxy as HTMLElement reference. It's one of those legacy features on the web you are likely to run into sooner or later even if you're not (intentionally) looking for it.

https://html.spec.whatwg.org/#named-access-on-the-window-object

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.

Krinkle · 2022-09-12T00:10:32Z

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 window.Set is available and used, but did not yet support the Set(iterable) constructor parameter. This is similar to Map where I left a comment about that. Basically, IE11 will return an empty set when given new Set(['foo'])) which means all values are seen as non-containers and thus go directly to recursion without checking pairs - hence infinite loop. One way is to use add() instead. Another is to limit use of the native version to only when it is new enough to support the iterable. I did the later in a follow-up to the draft squash branch. Will check again this week and then land if passing.

…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.

izelnakri added 3 commits August 16, 2022 03:45

Core: move equiv private functions to module cache

fcf1af5

Core: refactor equiv inner functions to ES6

5e367cb

Core: refactor equiv for easier readability

5e5ce7d

Small removals/adjustments to make the code more readable.

izelnakri force-pushed the equiv-refactors branch from d2915d7 to 5e5ce7d Compare August 16, 2022 02:03

Core: equiv optimize compareConstructors

4944d79

Krinkle reviewed Aug 16, 2022

View reviewed changes

Core: Remove array allocation for innerEquiv

dac41dc

izelnakri force-pushed the equiv-refactors branch 2 times, most recently from 757fdac to 4eef297 Compare August 16, 2022 23:29

Core: Optimize equiv to use a predefined Set

7dfa1cb

izelnakri force-pushed the equiv-refactors branch from 4eef297 to 7dfa1cb Compare August 17, 2022 00:14

izelnakri added 2 commits August 17, 2022 03:17

Core: Optimize equiv object comparison prop call

bce6d66

Core: Optimize equiv compareConstructors()

0ea1aa8

Makes code more readable and removes variable mutations in compareConstructors().

izelnakri changed the title ~~QUnit.equiv inner refactors~~ Core: QUnit.equiv inner refactors Aug 17, 2022

izelnakri mentioned this pull request Aug 17, 2022

Core: QUnit.equiv major ES6 refactor & optimizations [Step 2] #1701

Open

izelnakri changed the title ~~Core: QUnit.equiv inner refactors~~ Core: QUnit.equiv inner refactors [Step 1] Aug 17, 2022

Krinkle reviewed Sep 11, 2022

View reviewed changes

Krinkle added a commit that referenced this pull request Sep 12, 2022

[FIXUP] Limit use of native window.Set to when Set(iterable) is suppo…

6f3bd70

…rted Avoid IE11 failure, where we otherwise fail to do proper recursion checks against cyclical JSON. Ref #1700 (comment)

Krinkle closed this in fec7c1a Sep 14, 2022

Krinkle mentioned this pull request Oct 17, 2022

[2.19.2] Regression with deepEqual on hashes #1706

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Core: QUnit.equiv inner refactors [Step 1] #1700

Core: QUnit.equiv inner refactors [Step 1] #1700

izelnakri commented Aug 16, 2022 •

edited

Krinkle Aug 16, 2022

izelnakri Aug 16, 2022

Krinkle Aug 16, 2022

izelnakri Aug 16, 2022

Krinkle commented Aug 16, 2022

izelnakri commented Aug 16, 2022 •

edited

Krinkle Sep 11, 2022

Krinkle commented Sep 12, 2022

Core: QUnit.equiv inner refactors [Step 1] #1700

Core: QUnit.equiv inner refactors [Step 1] #1700

Conversation

izelnakri commented Aug 16, 2022 • edited

Krinkle Aug 16, 2022

Choose a reason for hiding this comment

izelnakri Aug 16, 2022

Choose a reason for hiding this comment

Krinkle Aug 16, 2022

Choose a reason for hiding this comment

izelnakri Aug 16, 2022

Choose a reason for hiding this comment

Krinkle commented Aug 16, 2022

izelnakri commented Aug 16, 2022 • edited

Krinkle Sep 11, 2022

Choose a reason for hiding this comment

Krinkle commented Sep 12, 2022

izelnakri commented Aug 16, 2022 •

edited

izelnakri commented Aug 16, 2022 •

edited