Fernando Padilla wrote: > I wonder, would it be too complicated to create something like > CopyOnWriteStanzaClone? > > I also wonder if there is some way to not generate all of the stanzas > right away, but only as they are processed. Basically following the > google-collections ideas of creating Iterables whose items are > generated/instanciated on the fly instead of a fully instanciated > collection. This won't fix the cpu use on cloning, but it could at > least reduce the max memory used depending on how many threads are > devoted to consuming the Iterable, versus processing the in-flight > stanzas.. etc.
Interesting. IIUC, that would mean lazy generation of stanzas: instead of having 100 stanzas waiting for 10 threads to process them, only 1 stanza + 100 to addresses sit there. Each time a thread starts processing a stanza, the actual forwarding stanza is generated from the original one + one 'to' address. Yet, I don't think our memory penalty is high enough to justify implementing this non-trivial logic. In fact, our stanza copies are pretty lean already. This whole discussion is rather theoretical anyway because we have no measured data to judge from. Bernd > > > On 9/1/09 2:47 AM, Bernd Fondermann wrote: >> Michael Jakl wrote: >> >>> Hi! >>> >>> On Tue, Sep 1, 2009 at 11:27, Bernd >>> Fondermann<bf_...@brainlounge.de> wrote: >>> >>>> It's not 'easier'. It would use less objects, yet not neccessarily much >>>> less memory though. Think about it: Queueing up the character data >>>> needs >>>> much more memory: what's now stored as 1 immutable inner object (and >>>> it's children) is then multiplexed into 1000s of character streams. >>>> Probably this would need much more memory! (And don't tell me now to >>>> store in special string objects what's unchanged, because this is what >>>> we are doing now right now with immutable objects!) >>>> >>> :D, no I won't. You're right the character data would take a lot more >>> space than the objects do now. >>> >>> Sorry for taking a bit longer to grasp that, and thanks for the >>> explanation ;) >>> >> No problem. You don't know how long it took me to figure this out in the >> first place! ;-) >> >> Bernd >> >
