[ https://issues.apache.org/jira/browse/SOLR-9546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15595162#comment-15595162 ]
ASF subversion and git services commented on SOLR-9546: ------------------------------------------------------- Commit f51340993aea7cca3053844284c115bddaa90215 in lucene-solr's branch refs/heads/branch_6x from [~noble.paul] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f513409 ] SOLR-9546: Eliminate unnecessary boxing/unboxing going on in SolrParams > There is a lot of unnecessary boxing/unboxing going on in {{SolrParams}} class > ------------------------------------------------------------------------------ > > Key: SOLR-9546 > URL: https://issues.apache.org/jira/browse/SOLR-9546 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Reporter: Pushkar Raste > Priority: Minor > Attachments: SOLR-9546.patch > > > Here is an excerpt > {code} > public Long getLong(String param, Long def) { > String val = get(param); > try { > return val== null ? def : Long.parseLong(val); > } > catch( Exception ex ) { > throw new SolrException( SolrException.ErrorCode.BAD_REQUEST, > ex.getMessage(), ex ); > } > } > {code} > {{Long.parseLong()}} returns a primitive type but since method expect to > return a {{Long}}, it needs to be wrapped. There are many more method like > that. We might be creating a lot of unnecessary objects here. > I am not sure if JVM catches upto it and somehow optimizes it if these > methods are called enough times (or may be compiler does some modifications > at compile time) > Let me know if I am thinking of some premature optimization -- 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