doModelChanged called before commitTransaction

GoJS
1

image
image770×526 43.8 KB

In our application we’re running into performance issues when loading in big nodeDataArray(s) or linkDataArray(s), while diving into the performance tab of google chrome I notice that doModelChanged is called, which takes most of the computing time. But I don’t think this is intended.

This is our diagram.ts, a class that extends the gojs.Diagram

 setNew(nodeDataArray: NodeDataType[], linkDataArray: LinkDataType[], staticData?: StaticDataType): void {
    this.clear();

    this.removeModelChangedListener(this._onModelChanged);

    if (staticData) {
      this.model.startTransaction("setStaticDataNew");
      this.model.modelData.staticData = staticData;
      this.model.commitTransaction("setStaticDataNew");
    }

    this.model.startTransaction("setNew");
    (this.model as GraphLinksModel).nodeDataArray = nodeDataArray;
    (this.model as GraphLinksModel).linkDataArray = linkDataArray;
    this.model.commitTransaction("setNew");

    this.addModelChangedListener(this._onModelChanged);

    this.undoManager.clear();
    this._emitHistory();

    this._forceRedrawOverview();

    this.focus();
  }

Even though our implementation expects the model changed to be triggered → 

    this.removeModelChangedListener(this._onModelChanged);
    // etc
    this.addModelChangedListener(this._onModelChanged);

Now the actual question; how can I either disable the modelChanged invocation (I couldn’t find anything in interface) and make sure it’s only done after the ‘setNew’ transaction is committed?

2

Internally there’s a model Changed listener that notices changes in the model and makes the corresponding changes in the diagram. So when you set the Model.nodeDataArray, it knows to delete all of the old Nodes and create new ones corresponding to the contents of the given Array.

Are you sure that your code is faster than just creating a new model and setting Diagram.model? It will automatically unregister your model Changed listener on the old Model and register it on the new Model, and use a new UndoManager. I don’t know what your _emitHistory and _forceRedrawOverview do, so I don’t know if you still need to call them. You do need to call Diagram.focus, if that is what you want.

3

_forceRedrawOverview; redraws the (gojs)overview forcefully, which also takes some computing time
_emitHistory; emits the gojs diagram transaction history to a pinia store.

I doubt that the code is faster than just creating a new model, I’ll apply that and I’ll let you know.

4

I applied it, but I’m surprised at the results. I’m sure I did something wrong.

The current implementation:

image
image915×693 79.6 KB

Creating a new Model instead:

image
image914×655 54.5 KB

What I made:

export function newModelFromNewData(newData: NewData): Model {
  const model = new Model(useLayoutsStore().getUniqueEntityId);

  if (newData.staticData) {
    model.modelData.staticData = newData.staticData;
  }

  model.nodeDataArray = newData.nodeDataArray;
  model.linkDataArray = newData.linkDataArray;

  return model;
}

Which is then set on the diagram:

diagram.model = newModelFromNewData(newData);
5

Don’t you need a new GraphLinksModel there?

How big are your models? I’m wondering if there’s some memory re-use happening in your original code. Although it seems too big a time difference to explain that.

6

Our Model inherits GraphLinksModel

Yeah I think we’re pushing GoJS to the limits with our usage.

I’m not sure what you mean with memory re-use.

Also, if you could elaborate on what’s big in models, in your opinion. Because the data I’m using right now is 7488 nodes and 40k~ links.

So it’s acceptable that it takes an amount of time, I’m just wondering how I can get the most out of the computing time without losing functionality.

7

If you primarily care about loading time, then you could try virtualization. But it’s significant programming work, and I don’t know what your trade-offs are.

Have you read Performance Considerations | GoJS ?

With each release we usually have a number of performance improvements, although the library is mature enough that I’m not sure that dramatic improvements are now possible without greatly restricting the functionality.

8

I have read that page, yeah. It has guided us a decent amount already.

If anything I think 10 seconds for loading 50 thousand ~ish items is acceptable. But I’ll continue to push forward, because faster and simpler is always better. I think I can achieve this by minimizing the node and link data types (They’re currently considerably big and I’m guessing this is causing the setting of the model / setting of the node/link data array to take the time it requires.)

At this time I’m not interested in virtualization.

9

Also, another question. Considering we’re talking about performance and this is another ‘issue’ I’m running into, which I can replicate using this page; Virtualized Diagram no Layout | GoJS Diagramming Library

if you zoom out in this diagram (for me atleast) the diagram becomes unresponsive and laggy, how could you achieve that zooming is (almost) always performant? Or is that something that isn’t possible?

[EDIT] considering this is handled in the Performance Considerations | GoJS page, but I couldn’t find any example.

10

The size of each data object (i.e. the number of properties it has) probably won’t make much difference in time. Some, since more memory means more time, but not a lot, and perhaps not noticeable.

Simplifying the node templates would help. Avoid unnecessary bindings, and particularly avoid TwoWay Bindings unless needed. Avoid unnecessary Panels.

The virtualized samples are inherently slower when scrolling or zooming, since they need to check for any Parts that they need to instantiate, or maybe destroy if outside of the viewport, each time there’s a “ViewportBoundsChanged” DiagramEvent. But there are other optimizations that are possible.

So I guess you are interested in performance after loading. That’s another reason to avoid virtualization.

11

Hi, I’d much rather have a 30 second load time with smooth scrolling, zooming and insertion than vice versa.

Please elaborate on “But there are other optimizations that are possible.” so I could implement these.

I’ll also take a look at the (node/link) templates, these are particularly big and filled with two way bindings at the moment that are probably unnecessary.

12

I meant other optimizations implementing virtualization.

We’ll review possible optimizations in our drawing code.

13

I understand! Keep me posted, thanks.