lucene-dev mailing list archives

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

    [ https://issues.apache.org/jira/browse/SOLR-13533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16859687#comment-16859687
] 

Varun Thacker commented on SOLR-13533:
--------------------------------------

{quote}bq.  The name's "Koen" by the way :P
{quote}
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.
{quote}
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: https://issues.apache.org/jira/browse/SOLR-13533
>             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
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message