Perf, Perf and... Perf

As the title suggest, this new release brings a few improvements in terms of performance. especially in the following 3 areas

1. there was a contribution, in this PR, done on the SlickGrid (core) lib to improve batch (insert/edit/delete) and so I also made the changes in the Grid Service to take advantage of them in the following methods (addItems, updateItems and deleteItems)
   • the test done in SlickGrid (core) is by inserting 100k rows in a grid (before: 1100ms vs after: 200ms)
2. date sorting is now 2x times faster (check full test logs in the PR)
   • on 50k rows with sorting 1 date column, before 1981.27ms and after 903.99ms => 2.1x faster
3. date filtering is now between 4x to 6x times faster (check full test logs in the PR)
   • all type of filters might benefit but the date is the biggest perf boost
   • on 50k rows with filtering 1 single date column, before 1471.19ms and after 246.01ms => 6.1x faster
   • on 50k rows with filtering 1 date range column, before 2695.77ms and after 591.40ms => 4.4x faster

You first reaction might be... how did you gain so much perf boost?
It all started when I was looking at where MomentJS is used in the lib, then I noticed that the Date sorting is actually parsing to a MomentJS object twice (1x for validating the date and 1x for the actual date) but that could be improved to do it in 1 parsing execution (use the same moment object to call momentDate.isValid() and then just use it for the sorting diff)... so with that done, I decided to take a look at date filtering to also avoid double parsing, but what I ended up finding, was that were being double parsed and worst than that, it was re-parsing the search values on every single cell value comparison (in other words if we have 50k rows, it was double-parsing the date in the search value 50k times and double-parsing the cell value 50k as well... so when it was supposed to compare and parse 50k rows + 1 time parsing for search value, it was in fact parsing over 4 times that which was about 200k parsing instead of 50k + 1 row... hence the perf boost between 4-6x faster). You can try it yourself, go over the GitHub demo page on Example14 and/or Example 19 then click on "50k rows" and test it out for yourself. If you are dealing with couple thousand rows, you might not notice the difference but make that 25,000 or 50,000 rows and you will surely notice the boost 🚀

Enjoy it

Enjoying the lib? Make sure to upvote ⭐ and/or Buy Me a Coffee ☕
... and if you already have, well then thank you 😺
Cheers

Features

• filters: add updateSingleFilter for a single external filter (#699) (677beb4)
• perf: huge filtering execution speed improvements (#694) (f93a24d)
• perf: improve date sorting speed (#691) (1040352)
• services: add bulk transactions in Grid Service CRUD methods (#687) (277e627)
• tests: add Cypress E2E tests to Bootstrap Tabs Example (#698) (b8d1d14)

Bug Fixes

• backend: incorrect item with GraphQL and useLocalFiltering (#697) (aa78e76)
• exports: Excel Export custom width applies the width to next column (#683) (fffa711)
• filters: don't use indexOf with NOT_IN_CONTAINS (#693) (844e167)
• frozen: hiding multiple columns when using pinning gets out of sync (#684) (a453d76)
• plugin: recreate header menu w/adding column dynamically, fix #689 (#690) (1b89e2f)
• build: enable tsconfig strict mode tsconfig, fixes #675 (#702) (7219249)
• filters: make sure Select Editor/Filter collection is filled (#700) (61e6599)
• filters: use defaultFilterOperator in range when none provided (#705) (a176037)
• helpers: should be able to highlight first row (0) (#701) (269f1e9)
• plugins: do not recreate header button plugin after re-render (#706) (da62a48)