Per my comment yesterday, I have found the overall design for networks of similar size to strongly influence these performance issues. It doesn't make the problem go away, but helps work around it.
Also, the basic speed of the UI on a particular machine is driven primarly by the clock speed of a single cpu given no architecture-specific optimization in the code. So that dual 300 MHz SGI is a slug compared to a cheap PC with a GHz processor, lots of RAM and a decent gaming card. Randall Hopper <[EMAIL PROTECTED]>@opendx.watson.ibm.com on 08/28/2001 08:04:37 AM Please respond to opendx2-dev@lists.berlios.de Sent by: [EMAIL PROTECTED] To: opendx2-dev@lists.berlios.de cc: Subject: [opendx-dev] Re: Big net slowing down (in UI) Chris Pelkie: |Hi Mark. I remember that monster. | |In my case, it's not the exec performance (that's not noticeably bad) |but the UI. I don't remember the earlier genetic parent of this net |slowing down though it was probably about as big. That's why I |wondered if people had seen this slowing response time in the UI |itself. It's too damn big to rebuild from the ground up, starting |from scratch to reset the module numbering back to 1. Hi Chris. Mark and I have definitely seen this, and it's still an issue with DX 4.1.3. The net from hell takes around 35 sec to load (second time, -uionly mode, net/macros/dx all in disk cache, local IPC X display), from OK-click to when you see the network and get UI control back. Switching pages may take up to 7 seconds, and creating control panels may take 5. BTW this is on a dual 300MHz R12k w/ 1GB mem. Randy -- Randall Hopper (mailto:[EMAIL PROTECTED]) Lockheed Martin Operation Support EPA Scientific Visualization Center US EPA MD/24 ERC-1A; RTP, NC 27711
