Re: [jira] [Commented] (SOLR-14013) javabin performance regressions

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [jira] [Commented] (SOLR-14013) javabin performance regressions

Ishan Chattopadhyaya
> 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) <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

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

Reply | Threaded
Open this post in threaded view
|

Re: [jira] [Commented] (SOLR-14013) javabin performance regressions

Noble Paul നോബിള്‍  नोब्ळ्
I'll look into this tomorrow my time. 

On Sun, Dec 8, 2019, 8:02 AM Ishan Chattopadhyaya <[hidden email]> wrote:
> 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) <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

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