2002 2003 2004 2005 2006 2007 2008 <2009> 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 | Index | 2002 2003 2004 2005 2006 2007 2008 <2009> 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 |
<== 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 Message
content: TSPA From: Jeff Hill
[mailto:[email protected]] 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 Message content:
TSPA |