[
https://issues.apache.org/jira/browse/SOLR-14013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16990579#comment-16990579
]
Yonik Seeley commented on SOLR-14013:
-------------------------------------
Even without the O(N^2) bug, which would be that hard to work around, this
auto-check-and-convert
on access is quite a trap (as seen above) that would be constantly biting devs
forever. It's also almost assuredly
the case that after just handling the N^2 bug, things will be slower overall
(often with more memory usage)
than before this attempt to save utf-8 conversion.
At this point I think the best thing to do is roll it back.
I support the idea of trying to use more CharSequence... but it's hard in
practice and we need to be careful.
The original fault lies with Java of course, which introduced CharSequence long
after String, and was
never fully converted/adopted ;-)
In the future, we should certainly benchmark any changes that are meant to
improve performance.
> javabin performance regressions
> -------------------------------
>
> Key: SOLR-14013
> URL: https://issues.apache.org/jira/browse/SOLR-14013
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Affects Versions: 7.7
> Reporter: Yonik Seeley
> Assignee: Yonik Seeley
> Priority: Major
> Attachments: test.json
>
>
> As noted by [~rrockenbaugh] in SOLR-13963, javabin also recently became
> orders of magnitude slower in certain cases since v7.7. The cases identified
> so far include large numbers of values in a field.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
