Reply to thread

Message: [QUOTE="Lew, post: 4197959"] How could you have accepted such an inefficient algorithm? Did you account for variations in load, garbage collection, anti-virus activity, Hotspot optimizations and the like? You know that micro-benchmarks are notoriously unreliable for general conclusions. For all I know, I could wind up saving a millisecond a week using HashSet compared to array for my load profiles. Don't forget to account for JVM load time! It occurs to me that the HashSet approach might suffer from infelicitous coding idioms that interfere with GC. Perhaps you're packratting. (See <[URL]http://mindprod.com/jgloss/packratting.html[/URL]>.) So what you need to do is make sure you carefully scope alllll your variables in the HashSet scenario, and thoroughly instrument your code so you can determine where you're colliding with the GC. (See <[URL]http://mindprod.com/jgloss/profiler.html[/URL]>.) You will, of course, need to institute a task force to performance-test your String-storage module, and to stand up a full suite of JMeter-based tests with detailed reports to management on whether that millisecond savings is sustainable. You'll also need contingency strategies, like, what if the program has to suspend? You'll need to serialize the data and deserialize it later to resume. Your performance team will need to consider the impact of the choice of HashSet vs. array for that functionality. You play this right and that String storage subsystem will merit an entire department and plenty of big iron with you as lead performance architect. Who knows? You might want up saving two milliseconds! -- Lew Raise your hands - who took all this bullshit seriously? Come on now, admit it! If you did take it seriously, you don't have what it takes to be a programmer. Get out now. I mean it. We don't want you. [/QUOTE]

Verification