[uDraw(Graph)-Users] How to use API updates

[Pieter Bellens]

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