> At this point I think the best thing to do is roll it back.
+1

On Sun, Dec 8, 2019 at 12:32 AM Yonik Seeley (Jira) <[email protected]> wrote:
>
>
>     [ 
> 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]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to