/cc @srowen @rxin

Test build #50810 has finished for PR 11090 at commit 5bbbf91.

• This patch passes all tests.
• This patch merges cleanly.
• This patch adds no public classes.

This kind of optimization always feels icky to me but it is pretty self contained. Are there more instances of this across the code that we can at least gather and handle in one place?

Reusing a Calendar object when the method will be called frequently is something recommended by "Effective Java" mentioned here. The more the method is invoked, the more performance improvement we get.

stringToTimestamp has the same problem but it uses different TimeZones instead of only a GMT TimeZone. We need cache the TimeZones in a hash map as I did in #11071. It is a little more involved and there is a case that the Calendar cannot be reused. So I'll keep it as is and make this PR as small as possible for now. If it is worth doing, I'll be happy to submit a new PR to address it.

I'm not arguing with the optimization, just moaning at the use of ThreadLocal. This one at least isn't likely to cause a memory leak. Yes, I understand that the more use, the better, which is why it'd be great to see if we can do this once to optimize lots of call sites.

However now that I am back in front of the computer I don't see any. Most are in test code. There are some silly calls to Calendar.getInstance().getTime() but these won't hurt.

Yeah, clear() doesn't un-set the time zone right? Which is OK in this method.

Is your 20 seconds improvement total wall-clock time difference over all records -- as in saving 6 nanoseconds per record? although I like optimization that sounds very small.

#11071 doesn't seem to be correct; is that intended to be part of this change?

@srowen The 20 seconds improvements is the difference of the stage time. i.e. before the patch, the stage runs 1.6 min. With this path it runs 1.2 min. It takes about 1 second to create 1 million Calendar records. So it saves about 1 microsecond per record.

Right, clear() doesn't un-set the time zone.

#11071 also wants to optimize the stringToTimestamp method. In my case, the code doesn't call stringToTimestamp. I just noticed it also creates Calendar and TimeZone objects which may have the similar issue. Anyway, we can fix the issue in stringToDate first as this is more obvious?

OK, I think this is OK to merge

Jenkins, retest this please

Test build #51269 has finished for PR 11090 at commit 5bbbf91.

• This patch passes all tests.
• This patch merges cleanly.
• This patch adds no public classes.

Thanks - I've merged this in master.