EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: Re: pvData introduction
From: "Kasemir, Kay via Core-talk" <[email protected]>
To: Timo Korhonen <[email protected]>, EPICS Core Talk <[email protected]>
Date: Fri, 27 Sep 2019 12:33:41 +0000
Hi:

>I guess that a similar rewrite will also happen for the C++ code and if I skip or reduce the text about introspection, a similar pattern will apply for both C++ and Java?
The alternative C++ implementation is just being started.
Can't say for sure if it will also just have 'containers'.
For the Java code, that seems to work great. Much smaller API, looks like I can do everything that's required: server & client, info/read/write/subscribe/RPC.
Only shortcoming would be that 'info' operations hands you an empty container.
So instead of for example
   StructureDescriptor "timeStamp": { LongDescriptor "secondsPastEpoch", IntDescriptor "nanoseconds", ... }
you get a
   PVAStructure "timeStamp": { PVALong "secondsPastEpoch" = 0, PVAInt "nanoseconds" = 0, ... }
The caller of PVAChannel.info() needs to know that the obtained PVAStructure is empty, it's only meant to describe the data.
Nothing keeps you from printing the timestamp with secondsPastEpoch, nanoseconds, .. and then you see that all values are 0, NaN, [].
Yes, that means inside the client you now have a PVALong with 8 wasted bytes for the long value = 0, a PVAInt with 4 wasted bytes for the int value = 0.
But in the bigger picture, those long, int, double values don't waste much space.
Would be bad if fetching the info for an NTNDArray got the actual int[2,000,000] data array, but all you get is int[0].
So memory-wise we're fine.
More important, the API is simpler, and the usage inside all the other operations might actually be faster, since you get the containers right away, no need to first allocate memory for the description hierarchy, then turn that into a container hierarchy, freeing the description hierarchy, ..
Still, what works well for the Java implementation may not be best for the C++ implementation.
One point of the alternate libs is to use the best of each language, not having to settle for the worst of both ;-)

Thanks,
Kay

Replies:
Re: pvData introduction Timo Korhonen via Core-talk
Re: pvData introduction Johnson, Andrew N. via Core-talk
References:
pvData introduction Timo Korhonen via Core-talk
Re: pvData introduction Kasemir, Kay via Core-talk
Re: pvData introduction Timo Korhonen via Core-talk

Navigate by Date:
Prev: Re: pvData introduction Timo Korhonen via Core-talk
Next: Re: pvData introduction Timo Korhonen via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: pvData introduction Timo Korhonen via Core-talk
Next: Re: pvData introduction Timo Korhonen via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020  2021  2022  2023  2024 
ANJ, 27 Sep 2019 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·