Avoid unnecesary prototype loop

[WebReflection]

As the whole purpose of the while (Object.getPrototypeOf(proto) !== null) loop seems to counter validate there was nothing else to loop, I believe it's a performance benefit, as well as smaller code, to simply check the prototype never more than 2 levels, with a graceful fallback in case the first check resulted into null already:

• the amount of Object.getPrototypeOf is fixed as 2 and never more
• there is less code to shrink/optimize for bundlers or minifiers

[netlify]

Deploy preview for redux-starter-kit-docs ready!

Built with commit e27b788

https://deploy-preview-581--redux-starter-kit-docs.netlify.app

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit e27b788:

Sandbox	Source
cold-wind-yyez2	Configuration
vigorous-fire-h1iu9	Configuration
lingering-water-pv986	Configuration

[WebReflection]

P.S. the 0 could be just a literal {} instead, it'd work exactly the same (but it'd be 1 extra char).

[markerikson]

This was originally implemented by @timdorr and we copied it from the Redux core.

I'm not inclined to change it unless there's truly a specific need, but I'll let him weigh in on it.

[timdorr]

Yeah, I'm not sure I really see the benefit here. Thanks, but this is fine as-is.

[WebReflection]

I'm not sure I really see the benefit here

is performance a concern of this project?

this brings O(1) vs O(n) on the plate, so it's faster, but also smaller.

every class based object, or Object.create(other) one, will crawl more than twice the prototype for no reason, and copy-pasting the initial solution shouldn't block this from improving, right?

[timdorr]

Theoretically, this runs in linear time, but practically it's constant time. The vast majority of users are passing in plain objects where this check is run. Those will have a single level prototype chain, meaning this while loop will run once and essentially becomes an if statement.

Regardless, we've been over this a number of times. The previous conclusion is this code isn't in the hot path of execution, so perfecting the execution time isn't critical and doesn't net any visible benefit. Even if it was, the compiler is going to optimize it anyway and it won't end up being more than a few opcodes.

[WebReflection]

The vast majority of users are passing in plain objects where this check is run. Those will have a single level prototype chain, meaning this while loop will run once and essentially becomes an if statement.

current code runs Object.getPrototypeOf at least twice or more, my code runs it never more than twice.

this code isn't in the hot path of execution, so perfecting the execution time isn't critical and doesn't net any visible benefit

to me it's a matter of logic. The while loop is redundant, and the if could be considered an edge case, covered by || 0 in this proposed change.

the compiler is going to optimize it anyway and it won't end up being more than a few opcodes.

if it's not critical path I understand, but the current code executes more instructions than it needs.

Metaphorically speaking, why would you prefer this code:

let current = i;
while (i--);
return (i + 1) === current;

instead of this?

return --i === 0;

anyway, your projects, your rules, I just personally welcome simple improvements, when no regressions whatsoever are presented, only benefits (even if logical, or theoretical).

Best Regards