Closed markw65 closed 8 months ago
|0
, I recall @Mingun having opinions. Typescript's reaction might change their mind.|0
is used only as idiomatic way to convert everything into an integer in JS. In theory, that also should help JIT that will see that the property variable has only integer shape. If something changed since those times, you can refactor code to reflect that.
While I agree that |0
is probably still better, a) Typescript doesn't understand it and b) I don't think this is going to make enough performance difference to matter, so let's move forward.
@markw65 do you want me to merge this now, or would you like to add another commit that turns on ts-check first? (regardless, will need a changelog)
Let's just go with this. I'll send a ts-check pull request shortly.
Btw, @Mingun is right that its faster:
node -p 'const start=Date.now(); let x = 0; for (let i = 0; i < 1000000000; i += (x || 0) + 1) {}; Date.now() - start'
1402
node -p 'const start=Date.now(); let x = 0; for (let i = 0; i < 1000000000; i += (x | 0) + 1) {}; Date.now() - start'
698
Similar results if you start with let x = undefined
.
But at an extra 700ms for a billion iterations, I don't think it would be possible to measure the impact on peggy...
I started to add jsdoc type annotations to generate-bytecode.js, and found a number of issues that typescript doesn't like. It seemed to make sense to fix those separately. But I can add the actual ts-check pull request (not yet submitted) to this one if you'd prefer.
Using
thing | 0
to produce an integer when thing could be undefinedmatch
field which is always one of -1, 0, 1 or undefined. Sothing || 0
does the same thing, and typescript is happy with it.Putting null into arrays that are supposed to contain numbers
literal
arrays, when thematch
field says that it won't be used. So using -1 is just as good.Object.entries
withlib
set toES2015
ES2017
is universal enough, we could just bump thelib
version. With this diff I've gone with switching toObject.keys
.