Github user vrozov commented on the issue:
https://github.com/apache/apex-core/pull/358
TODO: provide benchmark numbers for 4, 16, 32 and possibly 64 unifiers
comparing existing behavior with behavior after the commit.
---
If your project is set up for it, you can reply to this email
Github user vrozov commented on the issue:
https://github.com/apache/apex-core/pull/358
What is the reason unifier does not have it's own StreamMeta? IMO, it will
be better to introduce separate StreamMeta for unifiers instead of the locality
field that is used only for unifiers.
--
Github user sandeshh commented on the issue:
https://github.com/apache/apex-core/pull/358
@vrozov StreamMeta constructors are private. I will add a "clone" method to
that and assign a separate StreamMeta for the unifiers.
Also, I have seen some cases where unifiers are THREAD_
Github user tweise commented on the issue:
https://github.com/apache/apex-core/pull/358
Any benchmarking that demonstrates an improvement or motivates this change?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your p
Github user sandeshh commented on the issue:
https://github.com/apache/apex-core/pull/358
@tweise I will do the benchmarking. But at the outset, It skips the queue
between default unifier and the downstream, that should improve performance.
---
If your project is set up for it, you c
Github user tweise commented on the issue:
https://github.com/apache/apex-core/pull/358
That's theoretical the case for the default unifier and possibly not for a
different implementation. But in general I would aim for improvements to user
relevant scenarios.
---
If your project is
Github user vrozov commented on the issue:
https://github.com/apache/apex-core/pull/358
Most of the time default unifier (the one that passes tuples unmodified
from input streams to an output stream) is used. For that case, it is necessary
to benchmark the change (please see my previo
