Re: epicsSnPrintf is very slow when converting string arrays in GDD's aitConvert.cc

["Ernest L. Williams Jr." <ernesto@slac.stanford.edu>]

Hi Jeff,

Here is an example of some the large arrays we have running around at 
SLAC --LCLS:
FEE system
-------
DIAG:FEE1:481:DISPLAYWF.NELM   262144 
DIAG:FEE1:482:DISPLAYWF.NELM   262144 
CAMR:FEE1:455:IMAGE.NELM       307200 

E- system 
---------------
YAGS:DMP1:500:IMAGE.NELM       1.44768e+06
CAMR:IN20:186:IMAGE.NELM       307200
==========================================================================================

By the way, why don't we suffer from these issues with the IOC core implementation of the CA Server (i.e. rsrv)?
Or maybe, there are some subtle issues with large arrays even for iocCore?


One of the work-arounds we are considering for the purposes of IOC-Load balancing is to use a softIOC
in front of the source IOC.  Then most of our CA clients would make a connection to the softIOC
for a subscription to large arrays such as camera images.
What do you think?



Thanks,
Ernest





Jeff Hill wrote:
> Ø 0.000132 seconds per conversion - is epicsSnPrintf() really that slow?
>
> To answer my own question; no. I just finished adding 
> cvtFastPerform.cpp to libCom/tests and it looks like double to string 
> conversion take more like 3 uSec worst case which is about 44 times 
> faster than calculated.
> Nevertheless, I am curious. What is the largest array size being 
> communicated via the gateways at SLAC and at PSI? This might become a 
> big issue for arrays exceeding say one million elements (that are 
> converted to strings by the gateway).
> Still bug hunting.
>
> Jeff
> ______________________________________________________
> Jeffrey O. Hill Email johill@lanl.gov <mailto:johill@lanl.gov>
> LANL MS H820 Voice 505 665 1831
> Los Alamos NM 87545 USA FAX 505 665 5107
>
> Message content: TSPA
>
> *From:* Jeff Hill [mailto:johill@lanl.gov]
> *Sent:* Wednesday, July 22, 2009 6:13 PM
> *To:* 'Dirk Zimoch'; 'Ralph Lange'; 'Ernest L. Williams Jr.'; 'Amedeo 
> Perazzo'
> *Cc:* 'Core-Talk'
> *Subject:* epicsSnPrintf is very slow when converting string arrays in 
> GDD's aitConvert.cc
> All,
>
> I have discovered that a PCAS hang can occur when clients are fetching 
> very large arrays as strings. Just to convert the number of elements 
> that fit in a very large EPICS_CA_MAX_ARRAY_SIZE buffer with 
> epicsSnPrintf can take a very long time. It appears that this required 
> about 33 seconds during testing with EPICS_CA_MAX_ARRAY_SIZE of 
> 10,000,000. Based on that I calculate 33 / ( 10,000,000 / 
> MAX_STRING_SIZE ) is 0.000132 seconds per conversion. Is 
> epicsSnPrintf() really that slow?
> The solution appears to be to use the cvtFast library where it is in 
> range in GDD’s aitConvert.cc. The cvtFast functions are a bit scary in 
> today’s world - because a buffer size isn’t passed in – BTW. The 
> current workaround is to just not use them for buffer sizes below some 
> threshold.
> Jeff
> ______________________________________________________
> Jeffrey O. Hill Email johill@lanl.gov <mailto:johill@lanl.gov>
> LANL MS H820 Voice 505 665 1831
> Los Alamos NM 87545 USA FAX 505 665 5107
>
> Message content: TSPA