1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 <2016> 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 <2016> 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | RE: CSS 4.1: performance drop when using linking container and macros |
From: | "Mark S. Engbretson" <[email protected]> |
To: | "'Zumbruch, Peter Dr.'" <[email protected]>, <[email protected]> |
Date: | Fri, 4 Mar 2016 09:01:52 -0600 |
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 From: [email protected] [mailto:[email protected]] On Behalf Of Zumbruch, Peter Dr. 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 -- |