Time to render a diagram - analysis

[dmm9]

I have analyzed the time it takes to render some diagrams under different conditions, starting on the point where the user requests to open a diagram until the diagram is finally shown on the screen. The goal is to identify the factors that place a burden on the time to render a diagram, ultimately affecting the overall user experience and perceived quality. It might be of interest for GLSP adopters as well as for future development of GLSP itself.

I have analyzed 2 diagrams (one with few elements, other with lots of elements), and introduced some different combinations of network throttling to simulate a production environment.

TL;DR / Conclusions

• The size of the GModel and the download speed have the biggest impact in the time needed to render a diagram.
• Upload speed has medium impact in render time, and only in case computedBounds action is sent from client to server. In this case, the impact is less than download speed due to the ratio of downloaded/uploaded data. If computeBounds is not sent, then the upload speed has no noticeable impact in the time to render.
  • NOTE: this is a theoretical calculation of the impact. It seems that Chrome has not applied throttling to TX websocket, as seen by the similar results of (e2-e1) times under all conditions.
• Network latencies of ≤150 ms have a minimal impact. Higher latencies have not been analyzed.
• computedBounds action round trip
  • For big models, the size of computedBounds action message sent from client to server is as big as the message with the gmodel sent from server to client. For smaller models, the size is considerably smaller than the message with the gmodel.
  • The computedBounds action multiplies by 3 the network traffic.
• The computation of the GModel (method fillRootElement()) has some overall impact with big models. If the computedBounds roundtrip is removed and a download speed greater than 100Mbps is available, then the computation of the GModel becomes the most significant factor. For small models, the impact of the GModel calculation is negligible.
• Possible strategies to decrease time to render:
  • Compress network transfers, at least for messages where the gmodel is transferred. JSON compression can greatly reduce transfer size of the models (80-95% reduction according to google), and is usually not very expensive in terms of computation. For progress on this topic, see Is it possible to enable GZIP compression for the websocket? #1237
  • Avoid computedBounds action round trip. Transferring the gmodel 3 times seems superfluous (responsibilities mixed up?). It accounts for ~2/3 of the network traffic with big models. Either:
    • Improve GLSP protocol to avoid need for this round trip.
    • Shift all layouting operations to the client and disable computedBounds.
  • Improve computation of GModel. Although less relevant than the computedBounds round trip, for big models it accounts for most of the e0 to e1 time.

Test conditions

• Theia-based GLSP client, Java GLSP Server on localhost, EMF model, 2 Diagrams
  • Diagram 1: Big GModel with ~3000 top-level GNodes + subelements + edges
  • Diagram 2: Small GModel with ~50 top-level GNodes + subelements + edges
• Measurements performed in Chrome, using devtools with throttling settings applied to the websocket.
• Time To Render: defined
  • There are 4 main events recognized in the network trace:
    • e0: GLSP Client requests diagram to the GLSP Server - immediately after user action
    • e1: Server sends diagram to Client
    • e2: Client sends computedBoundsAction
    • e3: Server sends diagram to Client again
  • It is observed that the diagram is rendered immediately after the server sends the diagram for the last time.
• The throttling is configured symmetrically on RX/TX for simplicity. But this is not always the real case. Slower uplink speed would add up more delay when computedBounds is sent to the server.
• All tests have been performed after warmup. i.e. the diagrams have been loaded at least once before the test.
  • This loads all java classes before the tests. On the big diagram, the class loading adds 5 seconds.
  • This kind of fakes results, because users will always suffer the class loading at the beginning. But it also make the results comparable, as this analysis is focused on the network traffic.
• The EMF model is always pre-loaded in the resource set. No model loading/unloading happens on diagram open/close.

Result summary

Small GModel with ~50 top-level GNodes + subelements + edges

Throttling (Up/Down/Latency)	Time To Render (e3-e0)	Transfer size (in e1)	fillRootElement()	e1-e0	e2-e1	e3-e2
10Mbps / 10Mbps / 150ms	4.0s	1.2 MB	~0.13s	1.8s	0.2s	2.0s
100Mbps / 100Mbps / 150ms	0.9s	1.2 MB	~0.13s	0.4s	0.2s	0.3s
100Mbps / 100Mbps / 50ms	1.0s	1.2 MB	~0.13s	0.5s	0.2s	0.3s
none	0.5s	1.2 MB	~0.13s	0.2s	0.2s	0.1s

Big GModel with ~3000 top-level GNodes + subelements + edges

Throttling (Up/Down/Latency)	Time To Render (e3-e0)	Transfer size (in e1)	fillRootElement()	e1-e0	e2-e1	e3-e2
10Mbps / 10Mbps / 50ms	36.0s	7.5 MB	~2.1s	12.8s	1.4s	21.8s
10Mbps / 10Mbps / 150ms	36.1s	7.5 MB	~2.1s	14.0s	2.1s	20.0s
100Mbps / 100Mbps / 150ms	8.4s	7.5 MB	~2.1s	3.5s	2.1s	2.8s
100Mbps / 100Mbps / 100ms	7.9s	7.5 MB	~2.1s	3.4s	1.8s	2.7s
100Mbps / 100Mbps / 50ms	8.0s	7.5 MB	~2.1s	3.5s	1.7s	2.8s
none	4.6s	7.5 MB	~2.1s	2.2s	1.4s	1.0s

Data (only some samples)

big gmodel ~ 3000 top level nodes + subelements + edges

No throttling - 4.6s

10/10/150 - 36s

100/100/50 - 8s

small gmodel ~ 50 top level nodes + subelements + edges

No throttling (~1s)

[tortmayr]

Thanks for the detailled analysis! It`s very much appreciated.
I have created an issue (#1251) for this and we will look further into this.
Let's continue the discussion there.