Bug 48259 - Improve StatCalculator performance by using HashMap
Improve StatCalculator performance by using HashMap
Status: RESOLVED FIXED
Product: JMeter
Classification: Unclassified
Component: Main
Nightly (Please specify date)
PC All
: P2 enhancement (vote)
: ---
Assigned To: JMeter issues mailing list
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2009-11-21 21:58 UTC by ahit
Modified: 2009-12-14 16:59 UTC (History)
0 users



Attachments
Use HashMap for keeping values distribution instead of ArrayList (5.89 KB, patch)
2009-11-21 21:58 UTC, ahit
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description ahit 2009-11-21 21:58:14 UTC
Created attachment 24582 [details]
Use HashMap for keeping values distribution instead of ArrayList

There is no actually need to store *each* value separately in StatCalculator class. It's enough to save only counter of occurrences for every value. I propose HashMap class for that instead of ArrayList.

HashMap provides several major benefits:
 - It occupies less memory than ArrayList, especially for large data sets, because every inserted value will be kept within just one pair (key-value).
 - It has faster data insert (there is no need to call Collections.binarySearch() for every addValue(), insert into HashMap has O(1) complexity)
 - It still stays quite fast for reading. It calls for sorting in modified getPercentPoint() method, but sorts only keys. A number of unique keys is usually much less than total count of inserted values.

Sorry, I didn't check modified StatCalculator on real data yet, just run JMeter tests. I will do it after the weekend. But I think it will work fine.

I worked at SVN build 883037.
Comment 1 Sebb 2009-12-14 16:59:20 UTC
Thanks for the patch.

This has been applied to SVN:

URL: http://svn.apache.org/viewvc?rev=890589&view=rev
Log:
Bug 48259 - Improve StatCalculator performance by using HashMap

I made a few changes:
- instead of sorting the keys and using last or first to get max and min the code keeps track of the values.
- the sorted TreeSet is cached
- use MutableLong (Commons LANG) instead of Long