It may be reasonable to port most of those TupleTags to have an explicit, rather than generated ID, which will remove the need to inspect the stack trace.
However, as mentioned, the constructor shouldn't provide an unstable ID, as otherwise most pipelines won't work on production runners. On Tue, Apr 10, 2018 at 10:09 AM Romain Manni-Bucau <[email protected]> wrote: > Oops cross post sorry. > > Issue i hit on this thread is it is used a lot in tests abd it slows down > tests for nothing like with generatesequence ones > > Le 10 avr. 2018 19:00, "Romain Manni-Bucau" <[email protected]> a > écrit : > >> >> >> Le 10 avr. 2018 18:40, "Robert Bradshaw" <[email protected]> a écrit : >> >> These values should be, inasmuch as possible, stable across VMs. How slow >> is slow? Doesn't this happen only once per VM startup? >> >> >> Once per jvm and idea launches a jvm per test and the daemon does save >> enough time, you still go through the whole project and check all upstream >> deps it seems. >> >> It is <1s with maven vs 5-6s with gradle. >> >> >> On Tue, Apr 10, 2018 at 9:33 AM Romain Manni-Bucau <[email protected]> >> wrote: >> >>> Hi >>> >>> does org.apache.beam.sdk.values.TupleTag#genId need to get the >>> stacktrace or can we use any id generator (like >>> UUID.random().toString())? Using traces is quite slow under load and >>> environments where the root stack is not just the "next" level so >>> skipping it would be nice. >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book >>> >> >>
