Alex Karasulu wrote:
> Emmanuel,
>
> I was just thinking about your position on object creation. Namely the
> one that is against the creation of Tuple objects that represent TLVs.
> Your proposal to use pooling of these objects worries me a bit. It just
> makes me think there would be a lot of synchronization overhead. I may
> be wrong.
>
> However I started thinking, "why create Tuples at all?" Follow my
> concepts here for a sec even though we have not been discussiong these
> constructs: TupleProducers and TupleConsumers. A producer simply emits
> callbacks to a consumer and they are bound to each other. What if the
> callbacks did not pass in a Tuple as an argument but the components T, L
> and V of the Tuple instead.
Do you even need the L? You have the V at this point.
-enrique
> A stub, which is like the parser you
> mentioned, tracks and changes state as an automaton to populate its
> properties appropriately with the stream of Tuple events. The stub can
> be a TupleConsumer - really a tuple event consumer rather. This would
> eliminate object creation overheads and populate the stub.
>
> Thoughts?
>
> -Alex
|