You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Scope::region() and Scope::region_named() have intrinsic overhead since in order to report events about all sub-operators it has to observe the traffic that they send and receive. In order to combat this, timely should offer some sort of optional region that takes a boolean which determines whether or not the region acts like Scope::region()/Scope::region_named() or whether it does nothing and is a noop. Regions are incredibly helpful for debugging and visualizing dataflows, but in large codebases they can end up having non-trivial overhead.
Example Code
Since writing something like this is not only painful for developers (and not always possible because of the dreaded generics) but also hurts both code reuse and compile times
As per usual the normal Scope::optional_region() and Scope::optional_region_named() (or maybe Scope::optional_named_region()?) should be offered so that users can name the regions
The text was updated successfully, but these errors were encountered:
There is a related issue that might be good to think about at the same time, of "dynamic scope checking", where streams could check at runtime that they belong to the same scope before they are connected. This used to be largely enforced by types, as the scope type had a stack of lifetimes, but is a bit easier to get wrong with regions. It seems like it could be even more likely to get wrong, if we dynamically choose whether regions exist or not.
Scope::region()
andScope::region_named()
have intrinsic overhead since in order to report events about all sub-operators it has to observe the traffic that they send and receive. In order to combat this, timely should offer some sort of optional region that takes a boolean which determines whether or not the region acts likeScope::region()
/Scope::region_named()
or whether it does nothing and is a noop. Regions are incredibly helpful for debugging and visualizing dataflows, but in large codebases they can end up having non-trivial overhead.Example Code
Since writing something like this is not only painful for developers (and not always possible because of the dreaded generics) but also hurts both code reuse and compile times
Optional regions would allow writing this instead
As per usual the normal
Scope::optional_region()
andScope::optional_region_named()
(or maybeScope::optional_named_region()
?) should be offered so that users can name the regionsThe text was updated successfully, but these errors were encountered: