[
https://issues.apache.org/jira/browse/SOLR-12725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16604902#comment-16604902
]
David Smiley commented on SOLR-12725:
-------------------------------------
+1.
We might also want to keep track of which pattern last matched for the field we
are currently parsing. I surmise that the format is usually the same, and if
it's down the list then we'll waste a bunch of failed attempts that are
unlikely to match. Although there is some risk that it's wrong, and it's
possible the formats might be written in a way that is order-dependent, and
thus could produce a different result based on the sequence of document's
values. I'm not sure if it's worth worrying about that, or what the mitigation
might be.
> ParseDateFieldUpdateProcessorFactory should reuse ParsePosition
> ---------------------------------------------------------------
>
> Key: SOLR-12725
> URL: https://issues.apache.org/jira/browse/SOLR-12725
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Andrzej Bialecki
> Assignee: Andrzej Bialecki
> Priority: Minor
>
> {{ParseDateFieldUpdateProcessorFactory.parseInstant}} repeatedly calls all
> configured date parsers ({{DateTimeFormatter}}-s) for each incoming date-like
> field. However, it uses {{DateTimeFormatter.parse(dateStr)}} method that
> needs to allocate a throwaway instance of {{ParsePosition}}, instead of
> {{DateTimeFormatter.parse(dateStr, parsePosition)}}.
> Javadocs for this method suggest reusing (and reseting) a single instance of
> {{ParsePosition}} for multiple calls in order to reduce object allocations.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
