-
-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
simplify safe_not_equal and not_equal? #2886
Comments
This seems reasonable. Is there much of a performance gain in putting |
I am not arguing. But, I would suggest keeping the method I have changed fn export function is_mutable(obj) {
return typeof obj === 'object' || typeof obj === 'function'
}
export function safe_not_equal(a, b) {
return not_equal(a, b) || is_mutable(a)
}
export function not_equal(a, b) {
return a != a ? b == b : a !== b;
} |
Using this snippet... const obj = {};
const foo = function () { }
function safe_not_equal(a, b) {
return a != a ? b == b : a !== b || ((a && typeof a === 'object') || typeof a === 'function');
}
function safe_not_equal_simplified(a, b) {
return a !== b || (a && (typeof a === 'object' || typeof a === 'function'));
}
function is_mutable(type) {
return type === 'object' || type === 'function';
}
function safe_not_equal_simplified_indirect(a, b) {
return a !== b || (a && is_mutable(typeof a));
}
// --------------------
const iterations = 1e7;
function test(fn, a, b) {
console.time(fn.name);
let i = iterations;
while (i--) {
const object_differs = fn(a, b);
}
console.timeEnd(fn.name);
} ...then running things like @karuppasamy The whole point of this issue is to increase performance! As discussed, |
Just a question. The most important thing to optimize is when they are equal, correct? Because if they’re not, that leads to an update that probably makes any microoptimization dwarf in comparison? I might be missing something, but if that’s true, there’s no reason to do a NaN check when a === b anyway, and little harm in doing it when a !== b? |
@trbrc to be clear, is this what you're proposing? function safe_not_equal(a, b) {
return a === b
? (a ? (typeof a === 'object' || typeof a === 'function') : false)
: a === a && b === b;
} |
@Rich-Harris Yes, something very much like it. I have no idea where it sits with real world performance, but it looks to me like it should keep the original semantics but with less work to return false, and very similar work to return true. Do you agree? |
@trbrc's proposal is solid, imo. You just got a little bug with I also tried it without the polymorphic Little live test case if anyone also wants to check it out:
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
That is the current behavior in v5 Runes btw. UpdateI discovered there is an inconsistency between v5 Classic and v5 Runes about updates being triggered by re-assigning |
|
I was doing some profiling the other day and was mildly surprised to find that a lot of the time spent in Svelte — possibly even most? — was in
safe_not_equal
. It occurs to me that we might see some performance gains by changing the implementations thusly:The downside is that setting
x
toNaN
would trigger an update ifx
was alreadyNaN
. But I'm pretty sure that's a small enough edge case that we needn't worry about itThe text was updated successfully, but these errors were encountered: