Large performance drop with many equipment parameters

Hi Brandon,

I'm not sure if you are referring to performance issues in runtime, during compilation, or when working with the Graphics Builder. I guess the latter because you are referring to pgdynobj.dbf, which is not used in runtime.

Can you explain exactly what happens when you experience the issue, and where?

Regards,
Patrick

One genie to rule them all. I like it, sort of. I presume you mean Equipment Runtime Parameters. Equipment characteristics should be dealt with in the model, not on the page, so good work there. Though this is the sort of thing you are risking by resolving them at runtime unfortunately. Since these are a new feature is it likely that there isn't much experience out there. Since you are using the latest version, I assume your project is in support. I suggest you get in touch with them and share your concerns.

Just looking at the help for EquipGetParameter, I guess the function will need to go to the report server to get the info, and if it's having to do it every page scan or whatever cache time it has, could be a problem. Would you be able to set up some sort of caching system, so that on say the first scan of the page the parameters are stored into equipment specific page strings or animation metadata?

Hi Patrick,

I am talking about runtime, my apologies.
I mentioned pgdynobj.dbf because I have read here and there that during runtime, the size of pgdynobj.dbf directly relates to some sort of 'list of available triggers' that is scanned through, depending on what is being displayed at the time (available triggers for each object). Having an excessively large pgdynobj.dbf often therefore causes runtime to feel quite sluggish.
It makes sense to just simplify it and say if there's a lot going on on the page, even if it isn't changing, it'll slow things down. That almost goes without saying.

What happens, is that my fellow engineers created a series of popups, with varying amounts of objects that contain several Equipment Runtime Parameters each in them. There was a distinct point where larger pages went from 'expectedly slower' to 'suddenly, updating took ages, inputs were not being recognised, mouse down events had to be held for seconds to have a chance of being caught etc.'
This occurs for all runtime windows. Closing windows to reduce the number of references to Equipment Runtime Parameters causes it to go back go 'expectedly slow'.

Despite me insisting they should redesign the popups to only look at these on page open and set page variables for ones not expected to ever change, because 'expectedly slow' is not good enough - they want to go to give the clients higher end PCs instead, as long as this sharp drop in performance (the one being discussed here) is resolved.

I have suggested this, and the person responsible for maintaining this wholeheartedly disagrees.
I will look into doing this anyway, testing it, and presenting it to the team if it yields results.
For now, they've asked me to reach out and see if the unexpected slow down can be resolved - stating that the expected slow down of busier pages is just a question of processing power...
Thank you for the suggestion :) I will definitely look into it more, it seems like the sensible route.

Hi Brandon,

The symptoms you describe suggest the functions are being executed in foreground. Being a blocking function, that will result in serious performance problems impacting interaction.

I would recommend that these are moved to a background task, which you can read/cache/refresh at per client, or page open, or whatever the sweet spot is for the data and performance.

Once moved to a background task, the pages will be snappy again to display, however, you will still need to account for the gap between page display and parameter retrieval/processing. The purpose/design of those runtime parameters will govern what your options will be here.