@Mark, we are on version 1.5 and there is a definite slow down, at least for us with UI responsiveness (initial load of canvas upon logging in is close to a minute with about 2,000 processors on the canvas, with about 1,500 in the stopped state). We are planning on upgrading to 1.8.0 soon... Should there be a significant improvement in 1.8.0?
@Andy, thanks for the suggestion. I agree that NiPyApi would foot the bill on this one. Would this be a decent feature request? The ability to start/stop at the process group level currently exists. Does it make sense to also be able to disable at the Process Group level (not sure if there is a good case for it other than this scenario)? -Ryan H On Wed, Mar 27, 2019 at 2:07 PM Andy LoPresto <[email protected]> wrote: > Ryan, > > Reading through your email, my immediate suggestion was NiPyAPI. I think > Dan has wrapped some useful query methods there that could make this quite > easy. Obviously you are aware of it, but it’s still my best recommendation > for now. > > > Andy LoPresto > [email protected] > *[email protected] <[email protected]>* > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > > On Mar 27, 2019, at 10:58 AM, Ryan H <[email protected]> > wrote: > > Hi All, > > Is there a good way to change all processors on the canvas that are > stopped to a disabled state instead? The problem is that we have a large > amount of processors on our canvas that are in the stopped state which is > killing the UI performance (wouldn't want to go to each of the 2,000 > stopped processors individually and mark as disabled). We just learned that > this isn't an issue (with regard to UI performance) when processors are in > the disabled state due to the way status checks are performed. I'm sure > this could be scripted with NiPy or something else, but just wanted to > throw the question out to the community first before delving into this. > > Cheers, > > Ryan H > > >
