Community
Participate
Working Groups
At this time the tables doesn't handle well large sets of elements. Here are some measures I did: - With 5000 lines it takes 20s to create the representation, 5s to create an element and 10s to save. - With 13000 lines it takes 70s to create the representation, 11s to create an element and 21s to save. - With 26000 lines it takes 150s to create the representation, 56s to create an element and 80s to save. Anyway, above 5000 lines the table is barely usable. The solution described here https://bugs.eclipse.org/bugs/show_bug.cgi?id=457758 could strongly improve the creation/save time. But the "element creation" cost is related to the "refresh" of the table which probably needs its own improvement.
In my particular case, the table uses embedded trees. By default all of the table is expanded, if collapsed it would divide by 10 the number of lines. But AFAIK the current table implementation will load all of the lines anyway, expanded or not. The following solution could improve performance for the "embedded trees" case: - allow the specifier to tell if its table's trees must be expanded at opening or not - only load what is expanded
Coud you please put here the breakdown of the tasks and their timing you get when you refresh a table and when you create an element ? You can capture it by enabling the sirius profiler and using the corresponding view.
another question: is that an edition or a cross table ? We have tables of 40K elements which are being refreshed in less than 2 seconds, we need to track down what makes your case different.
(In reply to Cedric Brun from comment #3) > another question: is that an edition or a cross table ? > > We have tables of 40K elements which are being refreshed in less than 2 > seconds, we need to track down what makes your case different. Edition table, with embedded trees
(In reply to Cedric Brun from comment #2) > Coud you please put here the breakdown of the tasks and their timing you get > when you refresh a table and when you create an element ? > > You can capture it by enabling the sirius profiler and using the > corresponding view. [SWT]Refresh the SWT table :4002 occurences for 31179 ms [SWT]Change the collapse state of a line of the SWT table :22968 occurences for 46986 ms
After a little more analysis, two possible culprits have been identified: * the table refresh does a lot of "no-op" changes on the model (touch modifications), which are not currently filtered and end up costing a lot to handle, both by the cross-referencer and the post-commit changes analysis/minimization (BasicChangeRecorder.eliminateEmptyChanges()). For some reason on the reporter's test case the problem is most visible on DCellStyle.setBackgroundStyleOrigin(), called for each DCell in DTableElementSynchronizerSpec.doUpdateStyle(DCell cell, DCellStyle style). * TableHelper.hasTableDescriptionOnlyOneLineMapping() is called a lot and is relatively costly for such an innocent-looking test. https://git.eclipse.org/r/#/c/71155/ is an attempt to optimize it for the very common case where there *will* be more than one mapping. For the first issue about touch modifications, we'll try an isolated patch to avoid them in the case of setBackgroundStyleOrigin() and see how much it improves the original use case. If it confirms this analysis, we'll need a more general solution, maybe as general as https://git.eclipse.org/r/#/c/51256/ which globally filters TOUCH notifications for all the editing domain (or somehting in between these two extremes).
