What is the performance impact of the table grid editor ?

Complex setup with multiple grids on a single issue

Complex table grids with many dependencies can have a performance impact when viewing the issue.

One customer has setup an issue which is using 15 grids.  Some of these grids contain hundreds of rows, preloaded from a database.
We do see a slowdown when an issue is created, as the amount of information to be processed is significant.

For a simpler application (having multiple grids, loading simple lists) performance impact is negligible.
We have been testing this with the yourkit java profiler - comparing normal issue load time with issue load time when 2 grids are active.
We also use the grid internally quite intensively for the same type of use cases.



Search impact

There are 2 types of search

  • Criteria based search

  • Empty grid search to find all non modified grids

For the empty grid search, the add-on is not doing anything fancy. It has the same approach as any other custom-field, where a flag is indexed if the addon is modified.
This search is lucene based.  The criteria based search will actually query the underlying grid table using a where clause made up from the criteria.
These criteria might be specified in such a way that the query is taking a long time to complete (ie with subqueries and so on), and
secondly the list of values returned from the search might be huge, such that you get memory pressure (which has a GC impact).