Panel Startup Timing

[James Zukowski]

Until I started here a couple of years ago, the NOMADS panels that were being used were being SPAWNed as separate processes off our menus. Since that would allow for multiple 'sessions' using the same FID(0), it also led to occasional file conflict problems. We've been working to remove the SPAWNing part of the sequence and just have the menu PROCESS the panel directly after hiding itself ['show'(-1)]. With a little work to undo some of the added 'hooks' for the SPAWNing, this works pretty well.
The problem we're running into is timing. When the panel was SPAWNed, it loaded and displayed VERY quickly. However, directly PROCESSing the panel generally takes quite a bit longer, sometimes 6-8 seconds or more compared to the 0-2 seconds previously. And it doesn't necessarily correlate with the number of controls on the panel. Perhaps it can sometimes be chalked up to server utilization, but it seems to be a pretty consistent differential.
We're running RHEL 7.9 (64-bit) with PxPlus v15.1 and WindX via VPN. Most of the client PCs have been upgraded from Win 10 to Win 11.
After the latest wave of updates, we're starting to get some clear complaints about this. Any suggestions would be greatly appreciated.
Thanks, all!

[Mike King]

The easiest solution might be to just dynamically define unique FID values for every process.  You can then use the SETFID directive to set the session FID value.

FID(0) values can be up to 12 characters long -- assuming your code will accept that length. 

There are any number of ways you could generate the FID values perhaps using a specific range for each workstation and a control file where you can lock records to assure uniqueness of FID.

In theory you might be able use the process ID as a FID(0) value which would assure uniqueness.

[James Zukowski]

(Un)Fortunately, there are only about 30-40 left to remove the SPAWNing from, and we're developing all new panels without it; they're directly PROCESSed. They also seem to take a fair amount of launch time.

Is there anything I could look into?

[Mike King]

A PROCESS directive should take less time than spawning.   Perhaps the SHOW(-1) is causing a issue?

[James Zukowski]

I thought SPAWNing would take more time, too. I ran a brief test on our test server, and the first time I ran the panel, it came up in about 2 seconds. Exiting back to the menu and starting again took about 8 seconds, which remained consistent in subsequent runs. So...why would the first run launch so quickly and the others not? It doesn't make sense to me.

If we scrapped the show(-1) method, what would be the 'best' method to hide the menu? Move it WAAY off the screen, and move it back later? Something else? It seems like with Win 11 (or earlier), we've lost the ability to right-click an icon on the taskbar and move the window with the arrow keys, so shifting off-screen is a concern.

[James Zukowski]

Another observation: Tabbing from field to field also takes a LOT of time, even on the test server, which has VERY few users. The server utilization theory fails there...

[Mike King]

It sure sounds like there is something wrong with your setup.  The PROCESS definitely should run faster than a spawn.

One difference between the PROCESS vs spawn is that with the spawn you are starting from a clean environment whereas the PROCESS will inherit the environment from the menu. 

I would suggest you try enabling a timed trace on the PROCESS to see what might be causing the issue.
I might also make sure you aren't doing anything such as turning off turbo mode which would also explain the fact that general performance seems to be suffering when using PROCESS.

[James Zukowski]

Mike:
The timed trace was a great insight. It looks like each WindX transaction averages about 0.045 seconds on our network. So if I'm grabbing a property from 2 controls in 1 LET statement, or get one and set another, for example, that's 2 transactions, or about .09 seconds. MSE and obj(0) seem to be 0.09 each, etc.

The old panels had been set up as Resizable/Auto-Size. This caused multiple transactions per control once they were first drawn to see if they needed to be changed (which they didn't).

I reset these to Resizable/Custom and set appropriate anchor points for each control. This took a launch time of about 6.5 seconds down to less than 1.5.

Thanks for the help! GREATLY appreciated.

P.S.: We didn't do anything with Turbo Mode. If NOMADS did, then that's another story.

P.P.S.: Still haven't figured out why SPAWNing always worked so fast. There are bigger fish to fry at this point, and they'll all eventually go away, so it will be a moot point soon.