Chris, I've not seen this problem on the UI on large networks on the three platforms I use (AIX, Linux, Windows). But I tend not to have too much stuff per VPE page (i.e., only a screen-full or two at most), but have lots of pages. However, I did report a related problem with the exec 10 years ago (prior to the release of version 1.0) -- what Mark is referencing. However, much was done in subsequent releases to improve the situation. Greg's paper presentation at Vis95 (http://researchweb.watson.ibm.com/dx/proceedings/dx_paper/index.htm) outlines some of the key things that were done in the past. These and other efforts improved this situation enormously. I've not tested the optimizations that Randall added last year, although he posted that they were O(20%).
What Mark indicates as a primary problem I believe still applies. I have a few networks of similar magnitude to the ones that Mark cites. However, I don't have the speed problems he indicated. Sure, I see slowdown as the network accretes functionality. But once they got to be reasonably big, they haven't really gotten any slower. Part of the reason is I built a hierarchy (5-6 levels deep, if I remember right) of macros as he suggests, which hides a lot. When the "main" graph is evaluated the cache tags within macros are not, just the ones for the results (one of those key improvements made several years ago by Paula, I believe). The second is hand-tuning of the cache optimization in main and the macros. The automatic feature in the VPE is a good place to start. But further tuning can be done based upon what the network behavior should be. Finally, a big impact can be achieved via improved UI design independent of whether you are using dxui or custom code. A clean/simple user interface will require less for the exec to process that will slow things down. It also has benefits of being easier to use and maintain. So, Mark, you are in Aberdeen now, huh? Mark A Bolstad <[EMAIL PROTECTED]>@opendx.watson.ibm.com on 08/27/2001 09:21:14 AM Please respond to [email protected] Sent by: [EMAIL PROTECTED] To: [email protected] cc: Subject: Re: [opendx-dev] Big net slowing down (in UI) Yes. You may have heard reference to the "Network from Hell". That was ours (at least when I was at the EPA). It was around 2000 modules plus 1200 in macros (not including instances). The net was so slow that on a simple 30x30 grid (single layer) the frame rate was 3 secs per frame. Greg originally believed that it was the Switch and Route nodes that were killing us. We had over 500 of these in the top level of the net. The executive has to check these on every iteration, so the more you have the slower you go. The trick is to bury as many as possible into macros so they aren't checked every execution. The second idea was to dump the ui completely, and replace it with custom code. I had some good results initially, but that was working on a subset of the net. Randall wrote a python app that reads the net, extracts the ui elements, and replaces them with python ui elements (I presume they were Tk). It was pretty slick. However, once applied to the full network, our performance went in to the toliet again. We never had much luck in getting the performance up from the super-slow rate, other than trimming the network into pieces. Mark -- ---------------------------------------------------------------------- Mark A. Bolstad [EMAIL PROTECTED] Raytheon Systems Company (410)278-9149 Scientific Visualization Specialist U.S. Army Research Laboratory - HPC Major Shared Resource Center ---------------------------------------------------------------------- Chris Pelkie <[EMAIL PROTECTED]>@opendx.watson.ibm.com on 08/27/2001 08:11:04 AM Please respond to [email protected] Sent by: [EMAIL PROTECTED] To: [email protected] cc: Subject: [opendx-dev] Big net slowing down (in UI) >Lloyd said: >So, this might be an obscure tip for anyone that runs into this problem... > Thanks. I'm filing this one. Have you noticed an overall slowing of the UI response (on any system) as the number of modules gets over 1000 (or very large)? I'm not sure if it's the simple number of modules (including receivers, transmitters, etc. in the count), or because I've cultivated a genetic strain here from a large net of the past, which I opened, pruned off great gobs of stuff not needed, but kept gobs of stuff I did need and didn't want to recreate from scratch. I'm wondering if the fact that new Receivers are numbered in the 1000's (1023 in fact, but there aren't 1023 due to deletions during the historical development; only 738), if the slow response (5-6 sec from click to appearance of a new module in the editor, 10-12 sec to turn a page), is something to do with the namespace searching/hashing that is presumably going on under the covers. Any thoughts, anyone? The specific system is 4.1.1 on SGI Irix but the net was brisk when smaller (and other moderately large nets, say in the 200-300 module size) are still as brisk as ever. BTW, a quick and dirty module counter: grep node your.net | wc -l or make a nice list grep node your.net | sort > your.net.list (except the numbers aren't zero padded so the sort is sucky) Chris Pelkie Vice President/Scientific Visualization Producer Conceptual Reality Presentations, Inc. 30 West Meadow Drive Ithaca, NY 14850 [EMAIL PROTECTED]
