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.


  1. Avoid global custom field contexts
    Ensure that the custom field context is only applicable for the project / issuetypes where you want to see the grid.
    Else you end up with content in your grid table you are not expecting (in the case your grid configuration is initialized
    with a gd.query).
  2. Check memory settings. 
    When you have multiple concurrent accesses to issues (not necessarily the same) requiring the instantiation of one or more grid per access, you might end up with memory pressure. 



Search impact

There are 2 types of search

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).


Prepare a number of predefined filters when doing criteria based searches, which can be reused by your users.