3) If we use lazy instantiation for these fields, should the
corresponding "get" methods return null if the fields haven't been set?
 Or should they return an empty List/Set?  I would prefer null, but the
calling code has to be able to handle this.  I can make sure that any
calling code in JMeter will handle this properly, but this change could
break any user-written code that might rely on getting back a non-null
reference.  So maybe it would be better to return an empty List/Set for
now, and then next time we have a significant API change we can make
this change as well.

I'm for null. User-written code shouldn't be a concern here. We're on a "major development" phase now. If it's user-written, it can be user-fixed, too, can't it? If you introduce new bugs... well... we'll fix them.


Could be a good idea to do a quick review of all code calling those methods and ascertain how it will behave.

4) Today's SampleResult isn't thread-safe, so I assume my new
modifications don't have to be thread-safe either.  I haven't studied
the code enough to determine whether or not JMeter allows SampleResult
to be accessed concurrently by more than one thread.

SampleResults are designed to be created and populated by one single thread. Once this has happened, other threads may access them, but read-only, so it shouldn't be a problem.


> My lazy
instantiation code will probably be less thread-safe than the existing
code, so it could possibly break something that works today.  I can make
it thread-safe if it needs to be, but I won't add the extra overhead if
it's not necessary.

Go for it. Performance and heap memory usage is one of the big problems of JMeter now, so any step we take to improve that is very welcome.


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?

Salut,

Jordi.


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to