[jira] [Commented] (LUCENE-7115) Speed up FieldCache.CacheEntry toString by setting initial StringBuilder capacity
[ https://issues.apache.org/jira/browse/LUCENE-7115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15204896#comment-15204896 ] ASF subversion and git services commented on LUCENE-7115: - Commit 0926cecae647862760068d5eb0c8e8bc5afc6a79 in lucene-solr's branch refs/heads/branch_6x from [~gchanan] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0926cec ] LUCENE-7115: Speed up FieldCache.CacheEntry toString by setting initial StringBuilder capacity > Speed up FieldCache.CacheEntry toString by setting initial StringBuilder > capacity > - > > Key: LUCENE-7115 > URL: https://issues.apache.org/jira/browse/LUCENE-7115 > Project: Lucene - Core > Issue Type: Improvement > Components: core/search >Reporter: Gregory Chanan >Assignee: Gregory Chanan > Attachments: LUCENE-7115.patch > > > Solr can end up printing a lot of these objects via the JmxMonitoriedMap, see > SOLR-8869 and SOLR-6747 as examples. > From looking at some profiles, a lot of time and memory are spent resizing > the StringBuilder, which doesn't set the initial capacity. > On my cluster, the strings are a bit over 200 chars; I set the initial > capacity to 250 and ran tests calling toString 1000 times. Tests > consistently show 10-15% improvement when setting the initial capacity. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7115) Speed up FieldCache.CacheEntry toString by setting initial StringBuilder capacity
[ https://issues.apache.org/jira/browse/LUCENE-7115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15204890#comment-15204890 ] ASF subversion and git services commented on LUCENE-7115: - Commit 56292fd4efb1749533d5d7dcd7235ebe89187099 in lucene-solr's branch refs/heads/master from [~gchanan] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=56292fd ] LUCENE-7115: Speed up FieldCache.CacheEntry toString by setting initial StringBuilder capacity > Speed up FieldCache.CacheEntry toString by setting initial StringBuilder > capacity > - > > Key: LUCENE-7115 > URL: https://issues.apache.org/jira/browse/LUCENE-7115 > Project: Lucene - Core > Issue Type: Improvement > Components: core/search >Reporter: Gregory Chanan >Assignee: Gregory Chanan > Attachments: LUCENE-7115.patch > > > Solr can end up printing a lot of these objects via the JmxMonitoriedMap, see > SOLR-8869 and SOLR-6747 as examples. > From looking at some profiles, a lot of time and memory are spent resizing > the StringBuilder, which doesn't set the initial capacity. > On my cluster, the strings are a bit over 200 chars; I set the initial > capacity to 250 and ran tests calling toString 1000 times. Tests > consistently show 10-15% improvement when setting the initial capacity. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7115) Speed up FieldCache.CacheEntry toString by setting initial StringBuilder capacity
[ https://issues.apache.org/jira/browse/LUCENE-7115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15204286#comment-15204286 ] Mark Miller commented on LUCENE-7115: - +1 - makes sense to size for what's coming. > Speed up FieldCache.CacheEntry toString by setting initial StringBuilder > capacity > - > > Key: LUCENE-7115 > URL: https://issues.apache.org/jira/browse/LUCENE-7115 > Project: Lucene - Core > Issue Type: Improvement > Components: core/search >Reporter: Gregory Chanan >Assignee: Gregory Chanan > Attachments: LUCENE-7115.patch > > > Solr can end up printing a lot of these objects via the JmxMonitoriedMap, see > SOLR-8869 and SOLR-6747 as examples. > From looking at some profiles, a lot of time and memory are spent resizing > the StringBuilder, which doesn't set the initial capacity. > On my cluster, the strings are a bit over 200 chars; I set the initial > capacity to 250 and ran tests calling toString 1000 times. Tests > consistently show 10-15% improvement when setting the initial capacity. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7115) Speed up FieldCache.CacheEntry toString by setting initial StringBuilder capacity
[ https://issues.apache.org/jira/browse/LUCENE-7115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15202202#comment-15202202 ] Gregory Chanan commented on LUCENE-7115: I uploaded a patch based on a previous version, going to upload a new one shortly. > Speed up FieldCache.CacheEntry toString by setting initial StringBuilder > capacity > - > > Key: LUCENE-7115 > URL: https://issues.apache.org/jira/browse/LUCENE-7115 > Project: Lucene - Core > Issue Type: Improvement > Components: core/search >Reporter: Gregory Chanan >Assignee: Gregory Chanan > > Solr can end up printing a lot of these objects via the JmxMonitoriedMap, see > SOLR-8869 and SOLR-6747 as examples. > From looking at some profiles, a lot of time and memory are spent resizing > the StringBuilder, which doesn't set the initial capacity. > On my cluster, the strings are a bit over 200 chars; I set the initial > capacity to 250 and ran tests calling toString 1000 times. Tests > consistently show 10-15% improvement when setting the initial capacity. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
