[
https://issues.apache.org/jira/browse/LUCENE-8847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16860132#comment-16860132
]
ASF subversion and git services commented on LUCENE-8847:
---------------------------------------------------------
Commit 8b6a0d0964e74206a7dd0a7c321618197c53a391 in lucene-solr's branch
refs/heads/branch_8x from Koen De Groote
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8b6a0d0 ]
LUCENE-8847: Code Cleanup: Rewrite StringBuilder.append with concatted strings
(#707)
This specific commit affects all points in the casebase where the argument of a
StringBuilder.append() call is itself a regular String concatenation.
This defeats the purpose of using StringBuilder and also introduces an extra
alloction.
These changes should avoid that.
ant tests have run, succeeded on local machine.
Removing test files from the changes.
Another suggested rework.
> Code Cleanup: Rewrite StringBuilder.append with concatted strings
> -----------------------------------------------------------------
>
> Key: LUCENE-8847
> URL: https://issues.apache.org/jira/browse/LUCENE-8847
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Koen De Groote
> Assignee: Uwe Schindler
> Priority: Trivial
> Fix For: master (9.0)
>
>
> EDIT: Again, to clarify, please don't bother yourself with this ticket on
> company time, on personal time you could be working on something that makes
> you money or improves the product for your feature personally.
>
> This entire ticket is an afterthough. A look back at the code base that most
> people don't have the time for.
> ---------
>
> Code cleanup as suggested by static analysis tools. Will be done in my spare
> time.
> If someone reviews this, please also do not take up actual time from your
> work to do that. I do not wish to take away from your working hours.
>
> These are simple, trivial things, that were probably overlooked or not even
> considered(which isn't an accusation or something negative). But also stuff
> that the Java compiler/JIT won't optimize on its own.
>
> That's what static analysis tool are good for: picking stuff like that up.
>
> I'm talking about Intellij's static code analysis. Facebook's "Infer" for
> Java. Google's "errorprone", etc...
> These are the kinds of things that, frankly, for the people actually working
> on real features, are very time consuming, not even part of the feature, and
> have a very low chance of actually turning up a real performance issue.
> So I'm opting to have a look at the results of these tools and implementing
> the sensible stuff and if something bigger pops up I'll make a separate
> ticket for those things individually.
>
> Creating this ticket so I can name a branch after it.
>
> The only questions I have are: since the code base is so large, do I apply
> each subject to all parts of it? Or only core? How do I split it up?
> Do I make multiple PRs with this one ticket? Or do I make multiple tickets
> and give each their own PR?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
