Experimental Physics and
Industrial Control System

"Kasemir, Kay" <[email protected]> · Fri, 4 Mar 2016 16:38:46 +0000

Hi Peter:

What you’re doing, i.e. composing your display of several macro-based, re-usable subscreens, is fundamentally the right approach.

What you’re seeing is likely a result of BOY doing most work on the user interface thread.
When you open a display with linking containers, it will
1) Open the RICH_HV_2016.opi, which means file access, and that can be slow
2) Open HV_16x10.opi, which .. slow
3) Open HV_16ch_set.opi, .. slow
4) Open HV_Channel.opi, .. slow
It does cache the files, so it should only open HV_16ch_set.opi and HV_Channel.opi once, not 10 or 17 times.
Still, it opens those files on the user interface thread, subscribes to PVs on the user interface thread, and handles the received values on the user interface thread. If you have another *.opi already running, or for example a ‘probe’ on ‘sim://sine', you’ll notice that they stop updating, in fact all of CSS freezes while those files are loaded. 

Better would be this:
Open RICH_HV_2016.opi in some background thread. Then show it on the UI thread.
Connect to PVs in background, and as values arrive, compute what needs to happen in the background,
and finally update the text or whatever in the UI thread.
Same with HV_16x10.opi, HV_16ch_set.opi, HV_Channel.opi.
The basic RICH_HV_2016.opi will show up, initially with empty spaces for the embedded sections.
Then, as embedded sections load, they show up.
That way, even if file access is slow, nothing freezes.

Updating BOY to do the desired thing is not trivial because the basic model code is linked to GEF/SWT and not thread safe.
The display builder update project https://github.com/ControlSystemStudio/cs-studio/issues/1230 is addressing this.
It’s in fact doing the second scenario, but so far the implementation is limited to few widgets with few properties.
We’ll have an update at the EPICS meeting in May, where basically it should be ready for more developers to join.
It’ll be at best end of the year where you could start to use it for operational displays.

Meanwhile, I’m not sure what to suggest:
Properly structure your display files because it’s the right thing to do, and accept that for some time it’ll be slow loading?
Or use a monolithic display file because that loads faster?
Maybe only optimize for speed on displays that are opened/closed a lot.

Thanks,
Kay

> On Mar 4, 2016, at 6:19 AM, Zumbruch, Peter Dr. <[email protected]> wrote:
> 
> 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
> <ISEG_HV_monolith.tar.gz><ISEG_HV_modular.tar.gz>

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System