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]
