Re: DBE_PROPERTY events

[Zimoch Dirk via Core-talk <core-talk at aps.anl.gov>]

> This was an explicitly made technical shortcut to get this feature in.

OK. That relieves my concerns to change it. I was not sure if there was a
specific request to have that behavior, as it was prominently mentioned twice.

My current approach for property fields is to convert the value into a local
buffer (type epicsAny) and then compare the bytes with the old field content and
then copy if the value changed. This avoids to call the conversion function
twice at the cost of moving up to 40 bytes (but often less) from a local buffer
into the field.

This additional code path is only taken for property fields and only if monitors
are connected. Thus, it should not decrease the performance for non-property
fields. For property fields there is the additional work of comparing field_size
bytes with the old value. And in the case of a change to write the new value.

PR will follow soon.


On Thu, 2024-08-29 at 17:21 +0000, Johnson, Andrew N. wrote:
> On 8/29/24, 10:11 AM, Michael Davidsaver via Core Talk wrote:
>  
> On 8/29/24 06:20, Zimoch Dirk via Core-talk wrote:
> > Checking the EPICS base code, I found thus in dbPut():
> >      /* If this field is a property (metadata) field,
> >       * then post a property change event (even if the field
> >       * didn't change).
> >       */
> >      if (precord->mlis.count && pfldDes->prop)
> >          db_post_events(precord, NULL, DBE_PROPERTY);
> > 
> > So this behavior is on purpose, but I wonder why.
> 
> This was an explicitly made technical shortcut to get this feature in.
> 
> dbCore has no mechanism for previous value tracking, with this instead being left
> to individual record support to handle.  Doing otherwise would seem to require
> keeping a uniform previous value for every field, or eg. somehow encoding an
> association between value and previous value into the DBD.
> 
> The above code is inside the dbPut() routine that modifies the field being referred to, so earlier on it does have access to the old field value before the write happens, and to the new value after the write. Property fields (i.e. fields that have pfldDes->prop set to indicate they hold metadata) are all simple and can’t be arrays or double-buffered, so it might not be too hard to copy the old value before writing to it, then compare the new value afterwards to determine whether to post this change. The code that stores the old value and later compares it should only do those things for property fields when someone is monitoring this record (the condition in the if above), which should be a small overhead.
> 
> Thus I could see this as being possible, my analysis agrees with Dirk’s. I don’t have an objection to doing that as long as the measured performance isn’t significantly different.
> 
> - Andrew
> 
> -- 
> Complexity comes for free, Simplicity you have to work for.
>