refactor: optimize memoize use, misc cases - #10122
Conversation
a055458 to
057a566
Compare
057a566 to
f93d65b
Compare
Codecov Report
@@ Coverage Diff @@
## master #10122 +/- ##
==========================================
- Coverage 96.36% 96.34% -0.02%
==========================================
Files 63 63
Lines 9441 9419 -22
==========================================
- Hits 9098 9075 -23
- Misses 343 344 +1
Continue to review full report at Codecov.
|
sushantdhiman
left a comment
There was a problem hiding this comment.
LGTM, just one change
| * @private | ||
| */ | ||
| function addSetToArray(array, set) { | ||
| for (const v of set) { |
There was a problem hiding this comment.
return array.concat(Array.from(set))There was a problem hiding this comment.
'use strict';
function addSetToArray(array, set) {
for (const v of set) {
array.push(v);
}
}
const set = new Set([1, 2, 3, 4, 5, 6, 7, 8, 9]);
console.time('addSetToArray');
for(let i = 0;i<0xffffff;++i) {
addSetToArray([], set);
}
console.timeEnd('addSetToArray');
console.time('Array.from');
for(let i = 0;i<0xffffff;++i) {
[].concat(Array.from(set));
}
console.timeEnd('Array.from');
addSetToArray: 736.759ms
Array.from: 20121.014ms
On my machine using .concat(Array.from(set)) is about 25x slower.
The intention here is to make the code faster using sets, converting sets to arrays is a rather expensive operation, addSetToArray is the fastest way to do it pretty much, using Array.from would nullify all performance gained 😛
There was a problem hiding this comment.
I personally verified and Array.from is indeed really slow. Bummer, it was really concise. Will go with for + push approach
There was a problem hiding this comment.
|
I guess I enabled you to edit and there were conflicts, I would've rebased it for you :) |
|
@sushantdhiman mergy merge? |
| let keys = options.attributes.slice(); | ||
| if (this.constructor._hasVirtualAttributes) { | ||
| keys = keys.concat(this.constructor._virtualAttributes); | ||
| Utils.addSetToArray(keys, this.constructor._virtualAttributes); |
There was a problem hiding this comment.
I didn't merged because this still doesn't looks right to me, I think we should keep using array for _virtualAttributes
There was a problem hiding this comment.
Any reason why?
The overall code will be faster and it's not any less readable :P
There was a problem hiding this comment.
We are explicitly converting set to an array, this points out what we really need here is an array. Also simple concat on array is more readable and less complex
There was a problem hiding this comment.
What about the 5 other .has (previously .includes) calls? 😛
There was a problem hiding this comment.
has and includes got strong interchangeability , on other had for _virtualAttributes case we had to write special code to convert set to array, which indicate need of array rather than set
There was a problem hiding this comment.
The point of this PR was to primarily to get rid of memoize + includes and replace with sets since that's slows all reads. Also keep in mind the set is only converted for iteration.
I could change the code in this location to not create arrays at all.
There was a problem hiding this comment.
I could change the code in this location to not create arrays at all.
Hmm, give it a shot
There was a problem hiding this comment.
Done, waiting for build, I'm in the process of moving atm so I might take a while to reply.
b9bc8bf to
ac3ae90
Compare
|
Thanks @SimonSchick 👍 |
Pull Request check-list
Please make sure to review and check all of these items:
npm run testornpm run test-DIALECTpass with this change (including linting)?Description of change
Followup of #10091, re-implements the previous changes that were dropped for being too out of scope.
This PR also optimizes/streamlines type checks eg.
_.isTypetotypeof ... === 'type', lodash is generally slower for those as it uses alternative methods for type checking that are compatible with legacy browsers and the likes.