4

I am using JUNG for a project and when I am displaying relatively large graphs eg 1500 nodes, my pc would not be able to handle it (graphs are rendered but If I want to navigate the graph the system become very slow). Any Suggestions.

Ali
  • 617
  • 10
  • 25

3 Answers3

2

So, there are two things that JUNG visualization doesn't always scale very well right now:

  1. iterative force-directed layouts
  2. interaction: figuring out which node or edge (if any) is being referenced for hover and click events.

It sounds like it's the latter that you're running into right now.

Depending on your requirements, you have a couple of options:

  • (a) turn off mouse events, or at least hover events
  • (b) hack the visualization system so that lookups of event targets aren't O(m+n).

Simple solutions for (b) basically just partition the viewing area into smallish chunks and only sends events to elements that are in the same chunk as the pointer. (Obviously, the smaller you make the chunks, the more memory is required.)

We've had plans to do (b) (and a design sketched out) for some time but have been working on other things. Anyone that wants to help with a more permanent solution, please contact me.

Joshua O'Madadhain
  • 2,704
  • 1
  • 14
  • 18
  • I'm not sure if these are the biggest slowdowns. The panning/zooming of a graph leads to a ton of `repaint()` calls. This, in turn, generates a ton of `renderEdge` and `renderVertex` calls. The vertex fills come in second by a fair bit. In my experience, this has been > 40% of the CPU time. With that being said, I have no idea how you would _not_ repaint vertices and edges when the camera moves... – sdasdadas Sep 24 '13 at 19:09
  • 1
    True enough. These issues arise when you're panning and zooming, though, which is not always relevant, whereas layout is always a problem and hover/click often is. The issue you raise, incidentally, is why the visualization system has the capability to advance the layout without actually updating the visualization until you think it's stabilized, which at least keeps you from killing your CPU (as much) while the layout is updating. – Joshua O'Madadhain Sep 26 '13 at 04:58
  • I am investigating same issue now - has anything being improved in the last 2 years in the core JUNG library? I'm experiencing a major lag when scrolling a graph, which is under a 1000 nodes. – Rekin Dec 18 '14 at 09:42
  • @Rekin not in this respect, no. We've been working on other things. – Joshua O'Madadhain Dec 18 '14 at 15:21
  • 1
    @JoshuaO'Madadhain: Ok, I had an idea - optimizing by not drawing the invisible parts, my first results are here: http://i.imgur.com/XK0F8V0.png the code is in this gist: https://gist.github.com/anonymous/672d190b844410c1aa0e . It uses some open source RTree implementation. The results are quite encouraging. – Rekin Dec 18 '14 at 16:45
  • @JoshuaO'Madadhain: I profiled my execution during dragging and I got a pretty nice hotspot: DefaultVertexLabelRenderer.firePropertyChange(). It seems that the visualizer is using one JComponent to render the labels and before each render it sets up some properties, which in turn fires a lot of notifications. http://i.imgur.com/VhexkFd.png – Rekin Dec 18 '14 at 17:18
  • Finally! So, the LabelRenderer from JUNG is already heavily optimized - suppresses most notifications, but not for the "text" property. This is my bottleneck. Each time the text changes, the BasicLabelUI receives notification and in turn calls the method "BasicHTML.updateRenderer", which parses text as HTML... For each node, for each repaint event during scrolling! Now, I have pretty lengthy labels in my graph, which include line breaks. For me, it's easy to break those into separate labels and suppress the HTML interpreter. Case finished, sorry to bother You. – Rekin Dec 18 '14 at 17:37
  • @Rekin Glad you got it sorted out. :) – Joshua O'Madadhain Dec 18 '14 at 19:12
2

How much memory are you starting your VM with? Assuming your working on windows, looking at the Task Manager, does the VM hit the maximum amount of allocated memory and start using swap?

Binary Nerd
  • 13,872
  • 4
  • 42
  • 44
0

The problem probably lies with the calculation of your vertices' positions. The only layout that I've found fairly easy to calculate was the Tree Layout and obviously that's not suitable for all data sets.

The solution probably is to write your own custom layout with a lot less calculations than say an FRLayout.

Pieter-Jan
  • 1,675
  • 2
  • 19
  • 25