Cytoscape 2.7.0 Performance Report

Performance Across Versions of Cytoscape

the overall performance of Cytoscape remains on par with that of previous versions. As this report demonstrates:

http://chianti.ucsd.edu/~mes/performance

The only noticeable differences seems to be at startup time. The majority of the change in the startup time can be explained by the inclusion of two new plugins and one different plugin as part of the core plugins. The new plugins (Biomart and NCBI plugins) include many dependencies in the jars which accounts for the slow startup time. The additional startup time can be attributed to new initializations required for nested network management and placement of the Cytoscape desktop at the location it was in when the application last closed.

Janusz' slow dragging performance session file

The problem is that dragging a node in the supplied session file appears slow. If you drag a node fast enough, the rendering engine struggles to keep up with the mouse.

When I loaded this same session in versions 2.7.0, 2.6.3, and 2.5.2 of Cytoscape the performance was the same across the board (perhaps even slightly slower on version 2.5.2), so there do not appear to be any new performance problems that have been introduced into Cytoscape.

The reason for the slow dragging appears to be the high level of detail. The network has 99 nodes and 717 edges, which is well below the threshold of 2000 graph objects that determines the coarse level of rendering detail. If we force the network to render with a low level of detail, the performance improves to the extent that the node perfectly tracks the mouse cursor when moving.

This problem is entirely a function of the ding rendering engine and not any other part of Cytoscape. This was verified by tracing method calls at different parts of the code. When quickly moving a node side to side, the ding code is the only code that executes (e.g. VizMapper doesn't recalculate).

Improving the performance of the rendering engine would be fairly time consuming given the complicated layering of the different parts of the rendering system.

100,000 Objects

This is a set of three different tests that load different configurations of 100,000 "objects" in Cytoscape where an object can be a node, and edge, or a network itself. The three scenarios tested were:

• 1 network with 100,000 nodes and edges (total).
• 100,000 networks of 1 node each.
• 10,000 networks of 10 nodes each with one 10,000 node network where each node contains a nested network.

When this test was executed on my iMac, the first test of loading a single network with 100,000 nodes+edges ran in approximately 7 seconds. However both subsequent tests failed to complete over a two day weekend. It appears that when attempting to load upwards of 1000 networks in Cytoscape causes problems. While individual networks load quite quickly, the accumulation of networks seems to cause problems with event firing and gui updates that slow things down substantially.

Recursive Rendering of Nested Networks Test: Image vs. Network Rendering

This test compares the time it takes to render a network using the ding framework versus the time it takes to render a bitmap image of the network. The goal is to determine the whether attempting to directly render nested networks instead of rendering an image of the nested network is an approach worth pursuing.

This test measured the time it took to execute the GraphRenderer.renderGraph(...) method to calculate the times for the direct rendering approach. The image rendering time was also measured by calculating the duration of GraphRenderer.renderGraph(...), however this measurement was for a network consisting of a single node where the node has a nested network of the specified size.

The results show that image rendering time is effectively constant, regardless of network size, whereas directly rendering the network increases as the size of the network increases.

MCODE on Human Interactome

I used a human interactome network derived from the ConsensusDB database with 10856 nodes and 147021 edges. I ran MCODE three separate times and recorded the scoring duration of the algorithm. The times were (in milliseconds):

• 824473
• 831109
• 837228

Resulting in an average time of 830937 ms, or slightly less than 14 minutes.