Easy Performance Improvements (Reducing lodash filter and shallow clone in hot path)#134
Easy Performance Improvements (Reducing lodash filter and shallow clone in hot path)#134winrid wants to merge 4 commits intoscreeps:masterfrom
Conversation
…ne in hot path)
1. Lodash _.filter is about twice as slow as Array.filter, same with _.map.
2. _.clone() is much slower than {...obj}.
3. Tried to only change things in hot path and where risk seemed low, and limit logic changes.
|
Note that when I did this I didn't realize the API supported filters by lodash predicate objects - I didn't know people were doing that :)
EDIT - fixed |
|
Do you plan to add that check for filter predicate type? |
|
@sparr I was going to, but then it sounded like it wasn't going to be merged. It folks want the change I will finish it. |
|
The devs here haven't merged a lot of community contributions, especially lately, but they do take some. And PRs have value outside of being merged; you can find plenty of mention in other PRs of people using them on private servers despite them not being merged to the main repo. |
|
Okay! I'll try to wrap it up tomorrow then if you want to use it :) |
|
Full disclosure... I've run local servers for testing, but when I play online it will almost certainly be on the official servers. So don't implement this just for me, although I'd still appreciate seeing it available. |
…ce we were able to isolate the optimization in a shim.
|
@sparr Done. I was able to move the optimization, and add safety checks, to utils. This also reduces the scope of changes from 18 files to 11 (10 + utils.js). |
|
@artch This is done, if you are interested. However I am not able to run the tests yet due to node/python versions etc. |
_.filteris about twice as slow asArray.filter, same with_.mapif we need to just support taking a function as a filter._.clone()is much slower than{...obj}.