EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: epicsSnPrintf is very slow when converting string arrays in GDD's aitConvert.cc
From: "Jeff Hill" <[email protected]>
To: "'Jeff Hill'" <[email protected]>, "'Dirk Zimoch'" <[email protected]>, "'Ralph Lange'" <[email protected]>, "'Ernest L. Williams Jr.'" <[email protected]>, "'Amedeo Perazzo'" <[email protected]>
Cc: "'Core-Talk'" <[email protected]>
Date: Thu, 23 Jul 2009 12:25:36 -0600

 

Ø  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       
[email protected]
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

 

Message content: TSPA

 

From: Jeff Hill [mailto:[email protected]]
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       
[email protected]
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

 

Message content: TSPA

 


Replies:
Re: epicsSnPrintf is very slow when converting string arrays in GDD's aitConvert.cc Ernest L. Williams Jr.
Re: epicsSnPrintf is very slow when converting string arrays in GDD's aitConvert.cc Dirk Zimoch

Navigate by Date:
Prev: Re: Base R3.14.11-pre1 available for testing J. Lewis Muir
Next: Re: epicsSnPrintf is very slow when converting string arrays in GDD's aitConvert.cc Ernest L. Williams Jr.
Index: 2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: epicsSnPrintf is very slow when converting string arrays in GDD's aitConvert.cc Jeff Hill
Next: Re: epicsSnPrintf is very slow when converting string arrays in GDD's aitConvert.cc Ernest L. Williams Jr.
Index: 2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·