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