Bug 518622 - Response time of table diagrams
Summary: Response time of table diagrams
Status: NEW
Alias: None
Product: Sirius
Classification: Modeling
Component: Table (show other bugs)
Version: 4.1.1   Edit
Hardware: PC Windows 10
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: performance, triaged
Depends on:
Blocks:
 
Reported: 2017-06-22 05:45 EDT by Konstantinos Raptis CLA
Modified: 2018-03-14 06:34 EDT (History)
4 users (show)

See Also:


Attachments
two cross table diagrams (5.11 KB, application/octet-stream)
2017-07-04 05:59 EDT, Konstantinos Raptis CLA
no flags Details
A sample to reproduce the issues (173.17 KB, application/octet-stream)
2017-08-29 10:11 EDT, Konstantinos Raptis CLA
no flags Details
Sample data (836.87 KB, application/zip)
2018-02-09 15:00 EST, Pierre-Charles David CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Konstantinos Raptis CLA 2017-06-22 05:45:47 EDT
I have stream class in my meta-model that contain variables. Variables are associated with items. One attribute of variables is value.
I have a cross table with items as rows and streams as columns and in the cells I display the values of the variables.

In a 32x30 diagram (60% of the variables have no value)
-I can open the diagram instant
-When I update the values of all variables if the diagram is open it takes less than 2 seconds until I can see all the new values.
-Resizing the column width has 0.5 second delay

In a 32x250 diagram (60% of the variables have no value)
-The first time that I try to open the diagram it take about 2 minutes, after the first time I can open the diagram in about 1 second.
-When I update the values of all the variables if the diagram is open it take 2-3minutes until I see all the new values. If the diagram is closed while I am updating the values I can open it in about 1 second.
-Resizing the column width  has 1 second delay


Could you please tell me if the behavior that I am facing is expected?
Comment 1 Pierre-Charles David CLA 2017-06-26 08:55:22 EDT
Hi,

It's difficult to say without more details on your models and how your modeler is defined, but the times you see are very unusual. We certainly have some areas, especially in tables and trees, where performance is not very good, but several minutes to update is very surprising.

Some possible explanations:
* some expression(s) you used in your .odesign definition is very slow are called a lot more than you expect in the context of a Sirius "refresh" (the internal operation which synchronizes the representation with the state of the underlying semantic model);
* something specific in your use case triggers some "exponential" (or at least polynomial) algorithmic behavior in Sirius, which is not usually problematic.

The best way to move forward would be to profile your modeler, ideally with a real Java profiler (e.g. the proprietary YourKit, or VisualVM which is bundled in the Oracle JDK).

Sirius also features a profiler, but specific to some of its own operations. To use it:
* First you need to enable the profiler: Window > Preferences > Sirius: in the "Profiler" group, enable the "Profiling" checkbox.
* Open the profiler view: Window > Show view > Other... > Sirius Profiler > Time Profiler View.
* Initialize your scenario (e.g. open your table), and before starting it, click on "Reinit profiler" in the profiler view.
* Play your scenario, and at the end click on "Refresh view" in the profiler view. It will show you where (some of) the time of your scenario is spent.

This is not a full profiler, and only takes into account some specific parts of Sirius, so I cant't guarantee it will help pinpoint the problem. However as a first step it is much simpler than using a full Java profiler.
Comment 2 Konstantinos Raptis CLA 2017-07-04 05:59:57 EDT
Created attachment 269189 [details]
two cross table diagrams
Comment 3 Konstantinos Raptis CLA 2017-07-04 06:00:14 EDT
Hello,

I would like to thank you for your detailed response.
A part of my meta-model is: http://imgur.com/2rVbX9i
Attached you could find the two diagrams that I used for my profiler. In the profiler I displayed the same information with both diagrams. The only difference is that the "Flowsheet Results" diagram can display more than one sections.

"Flowsheet Results" diagram initial open (A 32x250 diagram, 60% of the variables have no value): http://imgur.com/a/8QDPh
"Section Result" diagram initial open (A 32x250 diagram, 60% of the variables have no value): http://imgur.com/a/XKY87
By initial open I mean the first time that I try to open the diagram (the diagram is created on the background)
The timings are comparable; however, in reality there is a big difference. For the "Section Result" diagram I can see the results and interact with the diagram after around 20 seconds (both in RCP and in the eclipse run-time environment). For "Flowsheet Results" diagram I see the diagram in around 20 seconds; however, the RCP or the eclipse run-time environment is not responding for the next 2 minutes!!!

If I update all the values of the variables while the diagrams are closed I reopen both diagram and interact with the diagrams within 1 second.

However, If I update all the values of the variables while the diagrams are open both the RCP or run-time environment is not responding for around 2 minutes as you could see in the images below.
"Flowsheet Results" diagram: http://imgur.com/a/ptt4U
"Section Result" diagram: http://imgur.com/a/dd8ul
Comment 4 Konstantinos Raptis CLA 2017-08-16 06:43:01 EDT
Hello,

I didn't work much on profiling since my last post, although I still don't understand why the same piece of information has such a big performance difference. 20 seconds when it is displayed from the Section and 2 minutes when it is displayed from the Flowsheet (Flowsheet is the parent of the Section).
Why the performance is so bad when I update the variables while the diagram is open?
Did you try to simulate similar cases?

Are you aware of the performance issues when resizing the width of a column?

Thanks!
Comment 5 Cedric Brun CLA 2017-08-28 10:11:16 EDT
(In reply to Konstantinos Raptis from comment #3)
> Hello,

> However, If I update all the values of the variables while the diagrams are
> open both the RCP or run-time environment is not responding for around 2
> minutes as you could see in the images below.
> "Flowsheet Results" diagram: http://imgur.com/a/ptt4U
> "Section Result" diagram: http://imgur.com/a/dd8ul

Just having a quick glance at those screenshots there are a number of things which I think might be suprising, it seems you have thousands of "refreshes" of the DTable where we would expect only one to happen. Can you elaborate on how you "update all the values of the variables" ? Depending on how you do it you might trigger a complete refresh each time whereas on, at the end, would be enough.

Beside this, it seems a significant time is spent in the old "Acceleo MTL" (expressions with [.../]) which have been replaced with AQL https://www.eclipse.org/sirius/doc/specifier/general/Writing_Queries.html#aql 

AQL is much faster, see http://cedric.brun.io/eclipse/introducing-aql/

I expect the migration from "Acceleo MTL"  to "AQL" to be trivial in your case, that would be a good way to pursue once the first issue is tackled but the main issue here would be to understand and avoid the thousands of refresh for a single operation.
Comment 6 Konstantinos Raptis CLA 2017-08-28 11:26:20 EDT
Hello,

thanks for your reply.

I update the values with a button. In the extension point org.eclipse.ui.menus I created a menuContribution with locationURI toolbar:org.eclipse.sirius.diagram.ui.tabbar?after=additions. In the menuContribution I created a command.

The command is associated with a handler. The handler class extends the org.eclipse.core.commands.AbstractHandler.

I update the values using Transactional Editing Domains because without it the variables remained the same.

For a 32x250 diagram if I update all the variables while the table diagrams are closed everything works fine and I can reopen the table diagrams without any problem. However, if I update all the variables while the diagrams are open both the RCP or run-time environment are not responding for around 2 minutes!
For a 32x30 diagram there is no problem. I don't see any difference if the table diagrams open or not.
Comment 7 Cedric Brun CLA 2017-08-28 11:31:51 EDT
Are you creating a single "RecordingCommand" for the whole operation or one for each variable  you changes ? If it is the later then that would explain the 1142 occurrences of the DTable refresh.
Comment 8 Konstantinos Raptis CLA 2017-08-29 08:09:47 EDT
Hello,

thanks for your comment! Yes, I was using many recording commands. I fixed it and now I don't see any performance issues!!

Regarding to the response time of the table diagrams I have only two issues left.
1. Resizing the column width has delay from 0.5 to 3 seconds, depending on the piece of information that a table diagram has.
2. Big table diagrams, for instance 3200x10, need around 20 seconds to load for first time, every next time need around 4 seconds. However, the same diagram from the parent side need around 60 second to load for first time, every next time need around 4 seconds. I personally find this time difference weird because it is for the same piece of information.

thanks!
Comment 9 Cedric Brun CLA 2017-08-29 08:32:21 EDT
You're welcome.

To investigate further those issues we would need to be able to run those and measure/profile using Yourkit. 
Is that possible for you to share all the projects which are required and the corresponding steps to do to reproduce it? If not, could you build an example reproducing the same issues but using Ecore as a semantic model ?
Comment 10 Konstantinos Raptis CLA 2017-08-29 10:10:39 EDT
Hello,

I created an example.

In order to reproduce the issues just create a new project on the runtime environment.

I added a button in the flowsheet diagram pallet that generates sample data.

You can observe the time difference between the Flowsheet Variables table and the Section Variables table the first time that you will try to open them.

The resizing of the column width is slightly faster than my project.

thanks!!
Comment 11 Konstantinos Raptis CLA 2017-08-29 10:11:32 EDT
Created attachment 270010 [details]
A sample to reproduce the issues
Comment 12 Pierre-Charles David CLA 2018-02-09 15:00:07 EST
Created attachment 272620 [details]
Sample data
Comment 13 Maxime Porhel CLA 2018-02-12 11:37:47 EST
Thanks for the detailed bug report and for the reproduction data which will allow us to investigate the issues you observed.

Nevertheless, please note that it's not yet in the scope of a future release.