EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: Re: memory management
From: Benjamin Franksen <[email protected]>
To: Jeff Hill <[email protected]>
Cc: 'Eric Norum' <[email protected]>, 'Ralph Lange' <[email protected]>, 'Matej Sekoranja' <[email protected]>, 'Marty Kraimer' <[email protected]>, 'Andrew Johnson' <[email protected]>, 'Ken Evans' <[email protected]>, 'Bob Dalesio' <[email protected]>, "'Kasemir, Kay'" <[email protected]>
Date: Thu, 03 Mar 2005 01:06:56 +0100
On Thursday 03 March 2005 00:35, Jeff Hill wrote:
> > -----Original Message-----
> > From: Benjamin Franksen [mailto:[email protected]] >
> >
> > On Wednesday 02 March 2005 22:02, Jeff Hill wrote:
> > > My solution to the wide character issue was to have the
>
> putChar
>
> > > and getChar interfaces pass type int. UTF-8 then becomes an
> > > implementation (an internal storage compression) issue.
> >
> > Ok, this is a possibility. But it means that, for instance,
> > an IOC will use wide characters throughout its code. Just
> > caring about our precious memory, you know... ;) That is,
> > provided it doesn't want to re-encode everything
> > again, of course...
>
> The stringSegment interface requires only that internal string
> tokens
> can be converted to a int sized universal code only when getChar
> and putChar are called, but there is no requirement that the
> implemenation use an internal storage of size int.

Yes, I understood that. As I wrote above, in order to avoid using wide 
character strings for storage, the user code has to re-encode the data into 
UTF-8.

> The getChar interface will be used in one character at
> a time situations where the storage overhead of an int can be
> safely
> neglected. Otherwise if there are any multi-token segments being
> stored
> they would only be stored in an implementation defined format
> accessed
> through the stringSegment interface. Anyways, that is the
> standard
> dataAccess approach: interface to data, but do not specify a
> storage
> format.

Yes and this is clearly a very versatile approach. The problem is that there 
is always some tradeoff between versatility and efficiency. Efficiency could 
be improved if we would enforce for instance a certain encoding, but probably 
not enough to make it worthwhile. Another approach would be to provided 
methods for the user code to make its encoding preference known to the data 
object, so that decoding and re-encoding could be avoided if external and 
internal encodings coincide. I am not sure how much this would complicate the 
interface, though.

Ben



References:
RE: memory management Jeff Hill

Navigate by Date:
Prev: RE: memory management Jeff Hill
Next: Re: EPICS base V4: iocCore database Benjamin Franksen
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: memory management Jeff Hill
Next: RE: memory management Jeff Hill
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  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 ·