You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Ishan Chattopadhyaya <ic...@gmail.com> on 2019/12/08 03:59:47 UTC
Re: [jira] [Commented] (SOLR-14013) javabin performance regressions
> 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) <ji...@apache.org> 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: issues-unsubscribe@lucene.apache.org
> For additional commands, e-mail: issues-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [jira] [Commented] (SOLR-14013) javabin performance regressions
Posted by Noble Paul <no...@gmail.com>.
I'll look into this tomorrow my time.
On Sun, Dec 8, 2019, 8:02 AM Ishan Chattopadhyaya <ic...@gmail.com>
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) <ji...@apache.org>
> 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: issues-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: issues-help@lucene.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>