On 24 Feb 2003 at 13:37, Jeremy Arnold wrote: > Hello, > After travelling, recovering from a cold, and catching up after the > above, I'm ready to tackle a couple more JMeter patches. But I've got a > couple of questions before I put the finishing touches on the patches > and send them in. > > The goal of the first patch is to reduce the size of SampleResult > objects. There are a couple of unused fields, and some other fields > which are sometimes used but take up a fair amount of memory even in > cases where they are not being used. I would like to fix these to > reduce memory usage and improve the serialization of these objects. > > 1) The "map" and "mark" fields don't appear to be used at all. I plan > to get rid of these completely.
Not sure what you mean by "get rid of". If you mean "prevent from being written to file", that's probably fine. The mark field is used, however in the SamplerResult object. It's the ResultCollector's way of knowing whether it has already recorded a particular sample. If two listeners are pointed at the same output file, you will not get duplicates or any other corruption of your data during test run and recording. I honestly don't even remember what "map" might be, so who knows? > > 2) "assertionResults", "subResults", and "files" can be used in some > cases, but not always. Instead of instantiating these fields > immediately, I plan to use lazy instantiation to create the List/Set > objects only when they are actually needed. Sounds fine. > > 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 don't mind null, but it needs to be documented somewhere - put it in the javadocs for now. > > 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. 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. SampleResult shouldn't need to be threadsafe. A sampleResult is created by one thread, and passed to the listener. Only one thread at a time has access to the object. > > I think that's it. If you have any questions, let me know. > Otherwise, I should have a patch ready soon after I get a thumbs-up on > the above. Looking forward to it! -Mike > > Jeremy > http://www.xirr.com/~jeremy_a > > > --------------------------------------------------------------------- > 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]
