In the Ignition Designer app, for views with big “breadth” (hundreds of embedded views), I have seen significantly higher processor usage after loading has finished. Here are some processor % usage measurements:
10% No view open
11-12% Simple view open
36% Complex view open (hundreds of embedded views)
For the complex view, processor usage is high even when all of the embedded views are static (for example, when the controller is offline and overlays show only an error condition). And, the processor usage remains high regardless of “design mode” or “preview mode”.
The high processor usage causes the Designer to act sluggish. For example, after selecting “Configure Events” on a button to show the script action, after the pop-up window appears, there is a 30 second delay before the script actually appears.
Is this a well-known issue? Is there a plan to correct this? Thanks.
1 Like
This is pretty well known in general but maybe not your specific example and the 30 second delay before a script appears.
Performance is something the Perspective team is continually working on. You didn’t mention what version of Ignition you’re using, but when it comes to Perspective performance staying up to date is your best bet.
If you can provide a window export that clearly demonstrates this the team might be able to do something with it as well.
I’m not actually sure degraded Designer performance is “well known” in this case - I was thinking more about the performance when it comes to load times for pages with many embedded views. But I do know in general the Designer performance in the Perspective workspace is something they’re aware of and working on too.
Thanks Kevin. Using Ignition 8.1.11 (latest). It almost seems like there is a pain threshold for number of embedded views. Here are more statistics:
Simple view 1 has 29 embedded views, 10.8% processor usage
Simple view 2 has 62 embedded views, 11.8% processor usage
Complex view has 223 embedded views, 36% processor usage
Almost seems like a threshold or cliff…when some number of embedded views is reached, the processor usage starts to rise quickly.
Note that the processor usage %'s are “steady state”, fairly constant after the initial view loading is complete in Designer.
Also note that all 3 views are using the same types of embedded views (some “high performance pipes”, some custom-built template views). These views were built before the new piping tool was available.
The pipping tool pipes have performance issues as well when you have lots and lots of them. Not sure exactly what the number is
Thanks for the heads-up…I was hoping that maybe replacing the “high performance pipes” with the new piping tool would help…
How have you constructed your pipes?
These were built using the “high performance pipes” templates that were provided before the new piping tool was released
Heh, I think those are “high performance” as in the “high performance HMI” design concepts.
2 Likes
Keep in mind every embedded view means a whole lot of extra scaffolding. If you can flatten things so that you’re using nested containers over embedding views, things are going to perform better.
I would expect the new pipes to perform better than an entire embedded view just for P&ID (even right now), plus their performance is undergoing optimization.
1 Like
Your best bet is going to get us a self-contained export of the project so we can see what is making your specific case slow. Without that we’re just going to be guessing. Constant CPU usage is not expected. What are the specs of the computer you’re running the designer on? 10% CPU usage at idle (no views open) is quite suspect…
2 Likes
Thanks everyone! @Carl.Gould it’s a Windows 10 virtual machine (4 processor cores, 8 GB memory) running in VMware Fusion on Mac OS. Besides Ignition server (gateway), SQL Server RDBMS is also on that same VM. With no views open in Ignition Designer, task manager shows Zulu Platform at around 5% processor, “Services and Controller app” at around 5% processor, and SQL Server bouncing around from 1% to 15% processor. Even with no views visible, I’m sure I am keeping Ignition server (gateway) somewhat busy with expression tags and transaction groups.
Thanks! I am using embedded views to create many instances of template views (with the necessary view parameters to set up each instance). The primary views (where the instances reside) are coordinate containers since we often have instances that overlap each other. Is there an alternate way of doing that using nested containers?
FYI - Just for fun, I deleted all of the “high performance pipe” embedded views off that “complex view”, leaving 99 embedded views (which are instances of template views that I created). With the pruned “complex view” just sitting there visible in the Ignition Designer, the average processor % dropped from 36% to 18.6%. Also, right-clicking on a button and selecting “Configure Events” has almost no delay before showing script (previously, there was a 30 second delay before the script appeared).
Lessons learned / Summary of findings
Perspective view containing embedded views in Ignition Designer
BEFORE - View contained 223 embedded views (“high performance” pipes)
While showing the view in Ignition Designer, processor usage was 35.8%, and there was a 30 second delay displaying button scripts.
FIX - Replaced all “high performance” pipes with 62 Perspective piping segments.
AFTER - While showing the view in Ignition Designer, the processor usage was 23%, and there was no delay displaying button scripts.
Note that the processor usage is 10% even with no view displayed in Ignition Designer (there are other “busy” apps including SQL Server Express on the same computer). Also note that this was evaluated on a Windows 10 virtual machine that had plenty of processor horsepower and memory capacity.
1 Like
Plenty = more than 10,000 cpu passmarks? Memory = more than say 24GB RAM (both ignition and especially sql are memory hungry)? Or...
