interactions loading function fails for some queries

[d2fong]

Desc.

Some interactions queries are really slow:

This one has been spinning for > 2 minutes and it is still going: http://appsbeta.pathwaycommons.org/interactions?source=ROCK1

Context

This particular query (ROCK1) was pretty fast before we fetched the other interaction types. I believe that it is partially due to the layout because TP53 ( a network 3x the size of ROCK1 ) loads quickly.

1. It loads fast if the layout is not run
2. It seemingly spins forever when the layout is run inside the loading function
3. Running the layout outside of this loading function seems to work.

[jvwong]

i noticed that the 'controls-state-change-of' bogs things down.

[d2fong]

I think it may have to do with the onStop function for cy layouts.

This doesn't work for ROCK1, but it works for every other example I have tried so far.

      cy.layout(_.assign({}, INTERACTIONS_LAYOUT_OPTS, {
        stop: () => {
          this.setState({
            loading: false,
          });
        }
      })).run();

This works for everything

      this.setState({loading: false});
      cy.layout(_.assign({}, INTERACTIONS_LAYOUT_OPTS, {
        stop: () => {
          this.setState({
            loading: false,
          });
        }
      })).run();
    };

It makes me believe there is something wrong with the stop() function but that doesn't explain why it only happens for ROCK1

[d2fong]

http://appsbeta.pathwaycommons.org/interactions?source=FGF9 Also doesn't load but I am not sure if it is for the same reasons. I think this is just a case of the pc web service just being slow.

[jvwong]

Not sure about the layout stuff but I can get FGF9 to load when I drop all but one ('phosphorylation-of') of the patterns on the PC/graph call.

I think we're hitting the ceiling for what we can do on the app-ui side (caching, reduced pattern types). We all know the graph calls are pretty expensive and likely never designed for this purpose.

[maxkfranz]

If the network size is an issue, let's just cap what the server sends back to 25 nodes. You'll get better layout quality as well, since COSE-Bilkent can't handle the nodes hidden by the slider. If the server only sends 25, you can just disable the slider entirely and use all the nodes that come back.