first we should understand why its still min 5x slower than MRI. hane nothing against this but it might be optimization done in the wrong end ...

@kares Thank you for your comment. I'm closing this PR. and will reopen it if needed.

I have been looking at this a bit this afternoon and caching the parser 3x the current results on HEAD. I believe the cost is object creation and initialization overhead for somethign which runs short. Making stateless lexer/parser (e.g. single result values with inputs passed as params) or other patterns could reduce this allocation cost but at the moment it seems pretty big.

With the current state we are now down to about 6x slower so things are getting a little closer. The caching makes us only like 40% slower but I think we can get this cost down other ways first before thinking about it.

A lexer which used ByteList+Joni would be decent. Another one interesting is not creating a linked list of patterns. A smaller one is eliminating bag and populating the hash directly. A tiny one is not re-retrieving all symbols out of the symbol cache but making them fields somewhere.

@enebo Thank you for your comment. Make sense. I will take a profile later.

@muga @kares I am curious on number or potential issues with f2e7b82 ... I got pretty big speed jump but I was using a very trivial format string and perhaps the actual matching logic will show up being slower than MRI?

@enebo looking good, maybe I would not count on most apps being reasonable much, guess we'll see 😉

@enebo Great, looks good 👍 My application, Embulk, should get big benefits from your change. It usually receives a dozen of format strings during org.jruby.Ruby instance's life. strptimeFormatCache size never grows.

I'm not sure (I haven't seen) but, if there would be actual applications that need to parse timestamp strings by a lot of types of formats, this logic might be slower than MRI's. A kind of cache size limit (like -Djruby.xxx.cache=16) might be necessary in the future.

@muga the memory size of this cache probably scales into 10k-100k without a lot of memory. A linked list of strings for format values seems like it should take very little memory? Although we may end up adding a cache size in the future if anyone reports this as a leak...

@enebo Ah I see. The linked lists might not consume a lot of memory because the number of elements in one linked list is about 10 or 20 usually. Your change should be OK.