On 1/25/21 11:00 AM, Axel Terfloth via Tech-talk wrote:
> Hello,
>
> i’m new to EPICS and take a closer look at it for evaluation purpose. To obtain a better understanding I started to dig deeper by implementing some tests which are based on the C++ examples. From a functional point of view everything I tried works nicely so far. Also the performance is generally very good in most of my test scenarios. Nevertheless one issue i came across is the time required for connecting to a channel via PVA. In this scenario I set up 4000 process variables and implement one client which implements high frequency put and get access to a quarter (1000) of these proces variables. On my machine (which runs all processes for now) if takes about 250ms for a single channel connection. Once all channels are connected is really fast. Nevertheless connecting 1000 pvs takes more than 6 minutes. I currently connect channel by channel using the PvaClient API in my tests. Is there a more efficient way to connect to a large set of channels? I would appreciate any hint.
Can you be more specific about what you application is doing? A common source
of slowdown with CA or PVA clients is for user code the is to perform network
operations in sequence. This can be done in parallel, which can give a nice speedup.
You might want to investigate my new (hopefully replacement) PVA library
which makes it easy to run many operations in parallel.
https://mdavidsaver.github.io/pvxs/
eg. the equivalent of 'pvget'
https://github.com/mdavidsaver/pvxs/blob/d0e82744d30256e36585b51af2704cc01a938e18/tools/get.cpp#L109-L132
If this isn't an option, then is the 'pvac' wrapper API which provides a
similar abstraction, though with more verbose syntax.
http://epics-base.github.io/pvAccessCPP/
eg. parallel get operations
http://epics-base.github.io/pvAccessCPP/examples_getme.html
- Replies:
- Re: Channel connection performance Veseli, Sinisa via Tech-talk
- References:
- Channel connection performance Axel Terfloth via Tech-talk
- Navigate by Date:
- Prev:
changing unit string to scale factor Randall Cayford via Tech-talk
- Next:
RE: changing unit string to scale factor Mark Rivers via Tech-talk
- 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
2025
- Navigate by Thread:
- Prev:
Re: Channel connection performance Marty Kraimer via Tech-talk
- Next:
Re: Channel connection performance Veseli, Sinisa via Tech-talk
- 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
2025
|