From pieter.bellens at student.kuleuven.ac.be Wed Jul 20 16:34:44 2005 From: pieter.bellens at student.kuleuven.ac.be (Pieter Bellens) Date: Wed, 20 Jul 2005 16:34:44 +0200 Subject: [uDraw(Graph)-Users] (no subject) Message-ID: <1121870084.42de610477484@webmail2.kuleuven.be> Hi, i ve been playing around with UDrawGraph for some time now, mainly for representing annotated direct acycling graphs. The graph itself is generated by another program, and piped to UDG using the variety of string commands from the API. When drawing larger graphs (e.g. 200 nodes, 600 edges) UDG slows down tremendously, taking on average 2 seconds to refresh the window after each update. Also, i observe a processor usage of +95%, and a pretty big memory footprint (almost 30Mb). My application repeatedly adds one node, or a collection of edges, to the graph. Pretty much in one burst, sending a few thousand of these operations to UDG through the pipe in a matter of seconds. Has anybody else observed this behaviour, and maybe found a remedy for it? Would it help if i decrease the number of communications, in favor of bigger updates (more nodes and edges in a single piped message)? Or is UDG simply not fit for larger graphs? thanks in advance, pieter bellens From mawe at tzi.de Thu Jul 21 09:58:35 2005 From: mawe at tzi.de (Mattias Werner) Date: Thu, 21 Jul 2005 09:58:35 +0200 Subject: [uDraw(Graph)-Users] How to use API updates In-Reply-To: <1121870084.42de610477484@webmail2.kuleuven.be> References: <1121870084.42de610477484@webmail2.kuleuven.be> Message-ID: <42DF55AB.9030807@tzi.de> Hello, Pieter Bellens wrote: > processor usage of +95%, and a pretty big memory footprint (almost 30Mb). > My application repeatedly adds one node, or a collection of edges, to > the graph. Pretty much in one burst, sending a few thousand of these > operations to UDG through the pipe in a matter of seconds. unfortunately the memory footprint of uDraw(Graph) grows, this is a known problem. But we can't solve it currently because it is a problem of the programming language we are using. Please tell me what operating system on which hardware configuration you are using. > Has anybody else observed this behaviour, and maybe found a remedy for > it? Would it help if i decrease the number of communications, in favor > of bigger updates (more nodes and edges in a single piped message)? Or > is UDG simply not fit for larger graphs? The incremental layout and update algorithms in uDraw(Graph) are implemented especially for getting updates in one API command. Every update results in the following steps in uDraw(Graph): 1. Insert the update into the graph 2. Recalculate the layout incrementally for the updated part 3. Redraw the graph for the updated part If you send one API command, these steps are executed once, if you send N API commands, they are executed N times. Regards, Mattias Werner uDraw(Graph) project -- Dipl. Inform. Mattias Werner Bremen Institute of Safe and Secure Systems (BISS) Bremen University E-Mail: mawe at informatik.Uni-Bremen.DE WWW: http://www.informatik.uni-bremen.de/~mawe/ From pieter.bellens at student.kuleuven.ac.be Thu Jul 21 12:37:27 2005 From: pieter.bellens at student.kuleuven.ac.be (Pieter Bellens) Date: Thu, 21 Jul 2005 12:37:27 +0200 Subject: [uDraw(Graph)-Users] How to use API updates In-Reply-To: <42DF55AB.9030807@tzi.de> References: <1121870084.42de610477484@webmail2.kuleuven.be> <42DF55AB.9030807@tzi.de> Message-ID: <1121942247.42df7ae7de13e@webmail2.kuleuven.be> Hi again, thanks for the swift reply...and here i go again: > unfortunately the memory footprint of uDraw(Graph) grows, this is a > known > problem. But we can't solve it currently because it is a problem of > the > programming language we are using. Please tell me what operating > system > on which hardware configuration you are using. > The large memory footprint is remarkable, but not really a problem. I observed it on the following machines: Linux 2.4.25 #9 SMP i686 unknown Linux 2.4.27 #7 SMP i686 unknown Linux (Debian, kernel 2.6.12.3) Acer laptop, amd1700+ > The incremental layout and update algorithms in uDraw(Graph) are > implemented > especially for getting updates in one API command. Every update > results in the > following steps in uDraw(Graph): > 1. Insert the update into the graph > 2. Recalculate the layout incrementally for the updated part > 3. Redraw the graph for the updated part > If you send one API command, these steps are executed once, if you > send N API > commands, they are executed N times. > Okay, but this doesn t really explain the slowing down of the program. I would logically expect UDG to be slower for a burst of very small updates, compared to a scenario where it has to cope with a smaller amount of bigger updates, true. But the problem is not slow responsiveness an sich, it is a *slowdown*. Initially, UDG can keep up with the external program that generates the nodes and edges. When the graph reaches a size of 100 nodes, 300 edges or so, it slows down to the point of being useless. Hence, the problem doesn t seem to be the large amount of smallish updates (only one node, or several edges), because initially, UDG can cope with those. Rather, i would think that the problem is that UDG can t cope with large-size graphs, no matter the size of the updates. Since UDG only accepts one update at a time from the pipe, the size of the update is irrelevant, wouldn t you say? I mean, if UDG displays a large graph at the moment, and it responds very slowly to a very small update (my present situation), i would expect it to be even slower, when sending over a large update (your suggestion). If you can assure me that the lack of responsiveness from UDG will disappear when using bigger updates, i m inclined to believe you, of course. But i would like to be absolutely sure before spending another week coding the changes, and finding out the opposite. I just don t see the reason why bigger updates would remove the problem. looking for answers, pieter bellens From mawe at tzi.de Fri Jul 22 12:46:43 2005 From: mawe at tzi.de (Mattias Werner) Date: Fri, 22 Jul 2005 12:46:43 +0200 Subject: [uDraw(Graph)-Users] How to use API updates In-Reply-To: <1121942247.42df7ae7de13e@webmail2.kuleuven.be> References: <1121870084.42de610477484@webmail2.kuleuven.be> <42DF55AB.9030807@tzi.de> <1121942247.42df7ae7de13e@webmail2.kuleuven.be> Message-ID: <42E0CE93.10507@tzi.de> Hello, Pieter Bellens wrote: > Initially, UDG can keep up with the external program that generates the > nodes and edges. When the graph reaches a size of 100 nodes, 300 edges > or so, it slows down to the point of being useless. Hence, the problem > doesn t seem to be the large amount of smallish updates (only one node, > or several edges), because initially, UDG can cope with those. Rather, i > would think that the problem is that UDG can t cope with large-size > graphs, no matter the size of the updates. Since UDG only accepts one > update at a time from the pipe, the size of the update is irrelevant, > wouldn t you say? I mean, if UDG displays a large graph at the moment, > and it responds very slowly to a very small update (my present > situation), i would expect it to be even slower, when sending over a > large update (your suggestion). the larger the graph, the more difficult it is to insert the update into the graph and to recalculate the incremental layout, that's true. I could try to find out, what slows down uDraw(Graph) if you send me the API log-file. You can create it by calling: uDrawGraph -log logfile.txt If uDraw(Graph) takes time S for a small update and time N*S for N small updates, the time for a large update containing all the N updates will be much smaller than N*S, because our algorithms are optimized for inserting large updates at once. If you send only small updates nothing can be optimized. > If you can assure me that the lack of responsiveness from UDG will > disappear when using bigger updates, i m inclined to believe you, of > course. But i would like to be absolutely sure before spending another > week coding the changes, and finding out the opposite. I just don t see > the reason why bigger updates would remove the problem. I can't assure you anything but if you send me the above logfile, I can have a look at it and maybe find out what the problem is. Regards, Mattias Werner uDraw(Graph) project -- Dipl. Inform. Mattias Werner Bremen Institute of Safe and Secure Systems (BISS) Bremen University E-Mail: mawe at informatik.Uni-Bremen.DE WWW: http://www.informatik.uni-bremen.de/~mawe/