From: Benjamin F. <ben...@be...> - 2010-04-16 21:25:20
|
On Freitag, 16. April 2010, Benjamin Franksen wrote: > The parent interface if this field is part of a PVStructure, else null. > > I also see that the methods getFieldOffset and getNextFieldOffset of > PVField seem to depend on this knowledge of a field about where in the > hierarchy it resides. > > Anyway, this part of the pvData design looks questionable to me. I would > have expected structural information to be something that the parent (if > any) and only the parent should know and be asked about, rather than the > field. In fact, I cannot see any good reason for the getParent method. > Correct me if I am wrong, but it seems that in order to get hold of a > PVField, client code ultimately has to start traversal at some top-level > structure. So it could as well remember (references to) the ancestors it > encounters on the way. Embedding structural information into fields means > that a field is much more tightly coupled to its containing structure > than necessary, which is, I think, something one tries to avoid nowadays. > (For instance, weren't iterators introduced just to avoid such a tight > coupling?) However, as I don't yet fully grasp the whole picture, there > may be deeper reasons for this decision, in which case I'd like to hear > about them. Ok, I think this has clarified itself, somewhat, by studying the implementation code. The class BasePVRecordField uses parent internally to propagate events upwards in the hierarchy. Since it is explicitly specified that changes to a field will trigger monitors for the containing structure, too, it seems almost unavoidable to store the parent inside the field, otherwise the parent would have to be searched. If the information needs to be there anyway, it seems natural to expose it through the interface. For the offsets relative to the top-level structure there is probably a similar story. I am still not convinced that it is a good idea, however natural it may seem, to expose this is the public interface. And, maybe, even the spec should be re-considered. I think it would be enough if client code gets the notification for the single field that changed. Propagating the event upwards seems to be unnecessary, IMO. If client code subscribes to a whole sub-structure, then this subscription can be propagated to the (sub-) fields *downward* at registration time, and similarly if the client subscribes for a subset of fields. This is my rationale (in addition to what I wrote before): The generic BasePVRecordField as implemented today, has quite a bit of memory overhead. I count 9 non-static data items in this class, meaning *at least* 36 bytes for each and every single field in addition to the field's data. To compare, in EPICS 3.x this overhead is (asymptotically) zero. <grumble>Fascinating, considering how many proposals for fixing deficiencies in 3.x were voted down, often on the grounds that they would cost a few more bytes *per record instance*.</grumble> It may appear that this is the price one has to pay for the increased power and flexibility. However, maybe not. EPICS 3.x gets away so cheaply partly because all of the overhead has been factored into the recordtype and subordinate field descriptions, which are (for all practical purposes) 'static', i.e. exist only once per type, not once per instance. In epics-pvData there is no longer any mention of the concept of recordtype or structuretype or anything similar. I dimly remember that (at least for the JavaIOC) this was not always so, and I wouldn't be surprised if one day these concepts will have to be re-introduced (at least in the implementation) for efficiency reasons. If this is done right, the overhead for individual fields can be reduced to two data items: the list of registered PVListeners (which will often be null) and a reference to the 'static' field description. Everything else can be either shared or lifted to the containing structure. BUT: such an implementation cannot provide a getParent method, nor getFieldOffset or getNextFieldOffset , and neither can it propagate events upward in the hierarchy. Cheers Ben |