Closed Valerionn closed 1 year ago
:exclamation: No coverage uploaded for pull request base (
feature/fix-insert-many-performance@18b3f6b
). Click here to learn what that means. The diff coverage isn/a
.
@@ Coverage Diff @@
## feature/fix-insert-many-performance #22 +/- ##
======================================================================
Coverage ? 95.12%
======================================================================
Files ? 74
Lines ? 1128
Branches ? 261
======================================================================
Hits ? 1073
Misses ? 55
Partials ? 0
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more
Some
insertMany
micro optimizations, leading to ~50% more Operations/s in my localinsert-many
benchmarks (but feel free to run the benchmarks on your PC as well):Changes, sorted by performance impact (DESC):
events
array if there are actually event listeners for theonInsert
event.primaryKey.has
to throwPrimaryKeyAlreadyInUseError
, instead just try setting the btree value, usingoverwrite = false
. If the key already exists, this function returnsfalse
and the error can be thrown there. This takes away one tree traversal forhas
, leading to better performance (unless the user setsclone = true
and regularly inserts entries which throw aPrimaryKeyAlreadyInUseError
, because the element is now cloned first, and then the insert afterwards checks if the element exists. But I think it's reasonable to optimize the non-error-case, especially since Error throwing is usually slow anyways).table[BlinkKey].storage.primary
etc. are now only done once in the beginning instead of once for each entity. This should slightly increase performance as well.Possible further improvements, which are breaking changes:
onInsert
event from{ entity: T }[]
toT[]
so that it's not necessary to allocate new objects for theevents
listinsertMany
function which doesn't return them)