Skip to content

Perf, Perf and... Perf
Compare
Choose a tag to compare
@ghiscoding ghiscoding released this 27 Feb 15:31
· 3156 commits to master since this release
v0.11.2
8522e33

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 Example2 and/or Example 3 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 🚀

Features

  • demo: add Example 13 Header Button Plugin (f345cd1)
  • editors: add a Clear (X) button to the Autocomplete Editor (#270) (ffbd188)
  • filters: add updateSingleFilter for a single external filter (#265) (20564a3)
  • perf: huge filtering speed improvements (a101ed1)
  • perf: improve date sorting speed (258da22)
  • perf: improve date sorting speed (#259) (a52f4fc)
  • services: add bulk transactions in Grid Service CRUD methods (#256) (03385d9)

Bug Fixes

  • backend: incorrect item count with GraphQL and useLocalFiltering (3996cf4)
  • build: enable tsconfig strict mode tsconfig (#269) (095fc71)
  • filters: don't use indexOf NOT_IN_CONTAINS (#262) (310be30)
  • filters: use defaultFilterOperator in range when none provided (#271) (993675f)
  • helpers: should be able to highlight first row (0) (#268) (a58be17), closes #527
  • plugin: recreate header menu when adding column dynamically (#257) (16c4984)
  • plugins: do not recreate header button plugin after re-render (09d44ec)
  • editors: styling issue found with input group and Bootstrap (18a9d02)
Assets 2
Loading