@Stephan, they are not copied when object reuse is enabled. This might be a problem, though, so maybe we should just change it in that place.
On Sat, Feb 28, 2015 at 7:57 AM, Ted Dunning <ted.dunn...@gmail.com> wrote: > This is going to have profound performance implications if this is the only > path for iteration. > > > > On Fri, Feb 27, 2015 at 10:58 PM, Stephan Ewen <se...@apache.org> wrote: > >> I vote to have the key extractor return a new value each time. That means >> that objects are not reused everywhere where it is possible, but still in >> most places, which still helps. >> >> What still puzzles me: I thought that the collection execution stores >> copies of the returned records by default (reuse safe mode). >> Am 27.02.2015 15:36 schrieb "Aljoscha Krettek" <aljos...@apache.org>: >> >> > Hello Nation of Flink, >> > while figuring out this bug: >> > https://issues.apache.org/jira/browse/FLINK-1569 >> > I came upon some difficulties. The problem is that the >> > KeyExtractorMappers always >> > return the same tuple. This is problematic, since Collection Execution >> > does simply store the returned values in a list. These elements are >> > not copied before they are stored when object reuse is enabled. >> > Therefore, the whole list will contain only that one reused element. >> > >> > I see two options for solving this: >> > 1. Change KeyExtractorMappers to always return a new tuple, thereby >> > making object-reuse mode in cluster execution useless for key >> > extractors. >> > >> > 2. Change collection execution mapper to always make copies of the >> > returned elements. This would make object-reuse in collection >> > execution pretty much obsolete, IMHO. >> > >> > How should we proceed with this? >> > >> > Cheers, >> > Aljoscha >> > >>