lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Varun Thacker (JIRA)" <>
Subject [jira] [Commented] (SOLR-13533) Code Cleanup - Performance
Date Mon, 10 Jun 2019 03:34:00 GMT


Varun Thacker commented on SOLR-13533:

{quote}bq.  The name's "Koen" by the way :P
I'm going to blame myself for typing without my morning coffee :) Sorry about that!
{quote}Which defeats the very purpose of using a StringBuilder.
My personal take on this though is that unless they are showing up in a profiler under real
load fixing these isn't worth it. However looking at your PR the changes make the code more
readable as well . I'll leave comments on the PR any changes are required

> Code Cleanup - Performance
> --------------------------
>                 Key: SOLR-13533
>                 URL:
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: Koen De Groote
>            Priority: Trivial
>              Labels: performance
> 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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message