The problem isn't the speed of the functions (they can easily cache their results). the problem is figuring out a good way to make all the code smart enough to grab the function and tell it to yield a result. Right now, most code expects strings to be held as TestElement properties. Not so hard to change that. However, some TestElements hold collections, which are often expected to hold strings, but could be functions. Without detailing a clever way of handling the functions, all JMeter code would be forced to examine every "String" property retrieved from anywhere in a TestElement and ask it if it's a function, and if so, execute it. And then, only when in the context of a running test.
I liked the idea of official "Property" objects from Oliver. I think it's a rather big task though, and complicated. Also, there's another case I forgot - and the real reason Samplers are PerSampleClonable: Default config objects - they write into the Samplers, but you don't want that to become part of the Sampler permanently. Of course, I can think of some interesting ways to deal with that too... I suspect you're right about the value of an object pool in this case. I think the number of TestElements created may be dwarfed by the number of strings and other objects created from cloning. -Mike On 24 Feb 2003 at 17:56, Jordi Salvat i Alabart wrote: > My experience using pools to avoid allocations is very varied. Many > times they don't really improve overall performance much (the cost of > keeping the pool and cleaning up after usage is too close to that of > allocating and collecting garbage). I've seen cases (bad > implementations) where they degrade performance significantly. > Complexity always grows. > > I'd definitely favour more restraint in using PerSampleClonable. > > Maybe the function-caused cloning could be reexamined, too? What's the > cost of re-evaluating a function? Looks like most functions are pretty > simple (actually all but the regexp ones). How often is a property of a > test element used twice, effectively obtaining a gain from this > "function result caching" feature? Could we require functions to be fast > (maybe by caching their own results) instead? Or maybe we could keep > variables and remove functions proper, moving necessary calculations to > pre/post-processors? > > Well... just popping out ideas. I think it's too early for such drastic > changes. We need some real performance analysis first. > > Salut, > > Jordi. > > Mike Stover wrote: > > On 24 Feb 2003 at 17:13, Jordi Salvat i Alabart wrote: > > > > > >>What about only cloning the elements when we actually need to modify > >>them? Or even just agree to never modify them and store the "variable" > >>data in the result instead? > > > > > > For the most part, this is what happens. TestElements are only cloned in three > > cases: > > > > 1. If they implement PerThreadClonable. Not really a problem since it's > > obviously > > necessary for those that do it, and it all happens before the threads start. > > 2. If they have functions that get replaced with real-time values during test > > runs. > > In this case, they get cloned at the time that their functions get replaced. > > 3. If they implement PerSampleClonable. There's probably some wiggle room here > > since AbstractSampler extends PerSampleClonable perhaps unnecessarily - most > > samplers could probably be written so as not to modify themselves. > > > > In any case, that still leaves a lot of cloning going on. A pool of test element > > objects would probably still help > > > > -Mike > > > > > >>Mike Stover wrote: > >> > >>>>A related issue is all that cloning (of test elements) that's happening > >>>>behind the scenes. I've not yet had time to actually measure, but I have > >>>>a feeling that it is tremendously expensive -- not the cloning itself, > >>>>but cleaning up all the garbage afterwards. Anyone got figures? > >>> > >>> > >>>It's occurred to me on more than one occasion that JMeter could use a TestElement > >>>pool that creates objects as needed, or provides currently unused blank objects. > >>>It > >>>would require changes to code so that TestElements are returned to the pool when > >>>done, but it would probably be worth it. > >>> > >>>-Mike > >>> > >>> > >>> > >>>>Salut, > >>>> > >>>>Jordi. > >>>> > >>>> > >>>>--------------------------------------------------------------------- > >>>>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>>For additional commands, e-mail: [EMAIL PROTECTED] > >>>> > >>> > >>> > >>> > >>> > >>>-- > >>>Michael Stover > >>>[EMAIL PROTECTED] > >>>Yahoo IM: mstover_ya > >>>ICQ: 152975688 > >>>AIM: mstover777 > >>> > >>>--------------------------------------------------------------------- > >>>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > >> > >> > >> > >>--------------------------------------------------------------------- > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>For additional commands, e-mail: [EMAIL PROTECTED] > >> > > > > > > > > > > -- > > Michael Stover > > [EMAIL PROTECTED] > > Yahoo IM: mstover_ya > > ICQ: 152975688 > > AIM: mstover777 > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Michael Stover [EMAIL PROTECTED] Yahoo IM: mstover_ya ICQ: 152975688 AIM: mstover777 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
