Reduce the time-complexity of the network initial positioning. #2759
Conversation
…ubstantial performance gain for large graphs.
lib/network/modules/LayoutEngine.js
Outdated
| } | ||
| else { | ||
| this.body.modules.clustering.clusterOutliers(); | ||
| console.log("outliers"); |
lib/network/modules/LayoutEngine.js
Outdated
| // if there are many nodes we do a hubsize cluster | ||
| if (level % 3 === 0) { | ||
| this.body.modules.clustering.clusterBridges(); | ||
| console.log("bridges"); |
| //Performance enhancement, cluster edges need only be simpel straight lines | ||
| let clusterOptions = { | ||
| clusterEdgeProperties:{ | ||
| smooth: { |
There was a problem hiding this comment.
It should be documented that, and when, this option gets overwritten by the algorithm.
There was a problem hiding this comment.
Just a quick note, this option is only used during the clustering phase of the initial layout. This is not user visible and doesn't influence the end result, it only halves the size of the nodes list during clustering...
|
I made a few simple performance tests with this options: {
physics: {
stabilization: {
enabled: true,
iterations: 10000,
updateInterval: 100,
onlyDynamicEdges: false,
fit: true
}
},
layout: {
randomSeed: 123
},
edges:{
smooth:{
enabled: false,
type:'continuous'
}
},
}I got the following results: Here less/smaller is better! I have to say I only ran the test one time and strong deviations (e.g. at 450 nodes) is propably due to random circumstances. It looks like this changes work really good for small networks (<300). But you can also see that there are also a significant increase in render time for 600<nodes<850 and 300 and 400. I have no Idea why, but whe should maybe fix this before merging this. If needed I could write some performance tests that run automatically. I could run these e.g. overnight on my 12 core workstation. But I'm not sure If I find the time to get to it this week. |
|
Hi, Re performance: I think this is mostly due to the higher memory usage in my patch. If this triggers a substantial GC round, this might explain the non-linear behavior in growing numbers of nodes. I'll redo this patch watching that behavior more closely, checking if that explains your numbers. Good to see that there are more performance patches. I suggest merging #2729 first and letting me update this to match that new situation. (and hopefully fix this for the whole range) Kind regards, |
Perfect. Thanks you very much. That makes it much easier! |
|
Hi Alexander, Can you provide some more details about those performance tests? You've provided the options, and I assume you used the performance example to generate the network? What is your end condition and how do you measure it? I like to run this and similar tests (e.g. a dense, highly-connected graph) myself, and wouldn't like to do double work:) Thanks! |
|
Hi Alexander, I've updated the patch to fix the comments you've made. I do recommend applying this pull request as is. The performance influence you measured is actually largely irrelevant: This patch only changes the initial layout, which takes a couple of seconds in large graphs. For the 500 nodes case this reduces the initial layout from around 3s to 1s on my machine. But your measurement looks at the stabilization as a whole, which includes the full physics ticks after initial layout. As far as I can tell the duration of the physics stabilization is largely dependent on the amount of needed steps, which doesn't seem to be significantly influenced by my patch, but is rather random. Running the 500 nodes case 5x leads to anything from 7 to 17 seconds of stabilization. So, for now, I recommend to apply this patch. |
|
@ludost Sorry for taking so long reviewing this. I was quite busy and just forgot about it. Sorry. |
…#2759) * Reduce the time-complexity of the network initial positioning. Very substantial performance gain for large graphs. * Remove unwanted console messages, extended comment.
Very substantial performance gain for large graphs. (>500 nodes)
Price of this patch is more complex code in an already complex part, but reducing large O complexity is important, for large graphs this reduces the rendering times substantially.