Experimental Physics and
Industrial Control System

This is not at all surprising and works much the same way with any of the applications that displays epics PV’s.

What is actually happening –

When many of these programs opens a display screen, all the searches for all the PV’s are performed all at 1 time, then typically the connects are done on the PV’s that exist. These happen fairly fast so most display values blink into existence almost instantly. If you did a search and connect PV by PV, you would see and second or 2 delay between each one, which gets worse the more you want to bring up.

Last time that I looked, most of these container and embedded displays are treated exactly like a new display, after all the normally processing is done, so each of them goes through the exact same process of searching for displays and then connecting to them.  (Think of it being similar to recursive opening of display screens.) So when you start to display many, many screens, you get that search and connect overhead again and again and again. You can watch them blink into existence and they have a nice consistent, rhythmic beat to them.  You basically know what is happening just by the delays.

To get the instant response that you want, these screen would have to be treated much like an C include file, where they are parsed when they are found in the sources, just as if they were some grouped set of components, or else you could try to have the developers force all the searches and connects to happen just once.

This is why many display screens use monolithic cut and paste screens instead of embedded displays. If you don’t bring up and destroy the screens often, it makes little difference – just part of the overhead to bring up all your displays. Other times, they get slightly . . . . annoying.

Me

Hi,

from a different setup I got a monolithic .opi-File for the control of a HV crate.

(see ISEG_HV_monolithic.tar.gz)

For a better maintenance I rewrote it and split it up into single opi Files which are then included by linking container widgets and configuring them using macros.

By this

“RICH_HV_2016.opi” includes

1 time “HV_16x10.opi” which itself links

10 times “HV_16ch_set.opi ” which again itself links

17 times “HV_Channel.opi“.

(see ISEG_HV_modular.tar.gz)

Simply comparing the file sizes and the lines of code I came down from 4.5 MB and ~115.000 lines down to 152kB and ~4300 lines.

But,

comparing the startup times (just counting the seconds) I see a difference of a factor of ~5, where the monolithic opi just took 1-2 seconds to come up.

Also the connection time to the see the variables slowed significantly down.

Is this a bad strategy / ansatz?

In general how to determine the performance more objectively?

Any comments welcome.

Best regards,

Peter

--
Dr. Peter Zumbruch
RBEE / Experiment Electronics // Controls group
E-Mail: [email protected]
Tel: +49-6159-71-1435 / Fax: +49-6159-71-2986

GSI Helmholtzzentrum für Schwerionenforschung GmbH
Planckstraße 1 / 64291 Darmstadt / www.gsi.de

Gesellschaft mit beschränkter Haftung
Sitz der Gesellschaft: Darmstadt
Handelsregister: Amtsgericht Darmstadt, HRB 1528

Geschäftsführung: Ursula Weyrich, Prof. Dr. Karlheinz Langanke, Jörg Blaurock
Vorsitzender des Aufsichtsrates: Staatssekretär Dr. Georg Schütte
Stellvertreter: Ministerialdirigent Dr. Rolf Bernhardt