[jira] [Comment Edited] (SOLR-9546) There is a lot of unnecessary boxing/unboxing going on in {{SolrParams}} class
[
https://issues.apache.org/jira/browse/SOLR-9546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15511196#comment-15511196
]
Pushkar Raste edited comment on SOLR-9546 at 10/3/16 3:29 PM:
--
Got you.
I will fix the {{Long getLong(String param, Long def)}} method only. It is not
as bad as I initially thought.
I don't even think that method is needed. Calling {{Long getLong(String
param)}} would do the same thing, won't it?
was (Author: praste):
Got you.
I will fix the {{Long getLong(String param, Long def)}} method only. It is not
as bad as initially thought.
I don't even think that method is needed. Calling {{Long getLong(String
param)}} would do the same thing, won't it?
> 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
>
> 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
[jira] [Comment Edited] (SOLR-9546) There is a lot of unnecessary boxing/unboxing going on in {{SolrParams}} class
[
https://issues.apache.org/jira/browse/SOLR-9546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15516844#comment-15516844
]
Pushkar Raste edited comment on SOLR-9546 at 9/23/16 4:08 PM:
--
I went through usage of most of the methods that return Wrapper types. I think
`SolrParams` class is encouraging usage of wrapper types (or people might are
just missing the fact that they might end up creating lot of wrapper objects).
Here are few are some places which can use primitive types by passing a default
value
{{SolrParams.getInt()}}
* {{HashQParser.parse()}}
* {{TextLogisticRegressionQParser.parse()}}
* {{CloudMLTQParser.parse()}}
* {{SimpleMLTQParser.parse()}}
{{getBool()}}
* {{ZkController.rejoinShardElection()}}
* {{DumpRequestHandler.handleRequestBody()}}
* {{PingRequestHandler.handleRequestBody()}}
* {{MoreLikeThisComponent.process()}}
* {{BinaryResponseWriter.write()}}
* {{JSONResponseWriter.write()}}
* {{PHPResponseWriter.write()}}
* {{XMLResponseWriter.write()}}
JVM might do something smart for `Boolean` type, since there are only two
possible values.
There are some *test* classes as well.
There are some other classes that do depend upon values being `null`.
* I can modify all the places mentioned above to call get(param, df)
version, or
* We can simply add `getPrimitive()` methods that return default value
in absence of a param, to make it clear that these methods would return a
primitive
Another possibility, I am overthinking here :-), and this ticket can be closed.
was (Author: praste):
I went through usage of most of the methods that return Wrapper types. I think
`SolrParams` class is encouraging usage of wrapper types (or people might are
just missing the fact that they might end up creating lot of wrapper objects).
Here are few are some places which can use primitive types by passing a default
value
{{SolrParams.getInt()}}
* {{HashQParser.parse()}}
* {{TextLogisticRegressionQParser.parse()}}
* {{CloudMLTQParser.parse()}}
* {{SimpleMLTQParser.parse()}}
{{getBool()}}
* {{ZkController.rejoinShardElection()}}
* {{DumpRequestHandler.handleRequestBody()}}
* {{PingRequestHandler.handleRequestBody()}}
* {{MoreLikeThisComponent.process()}}
* {{BinaryResponseWriter.write()}}
* {{JSONResponseWriter.write()}}
* {{PHPResponseWriter.write()}}
* {{XMLResponseWriter.write()}}
There are some *test* classes as well.
There are some other classes that do depend upon values being `null`.
* I can modify all the places mentioned above to call get(param, df)
version, or
* We can simply add `getPrimitive()` methods that return default value
in absence of a param, to make it clear that these methods would return a
primitive
Another possibility, I am overthinking here :-), and this ticket can be closed.
> 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
>
> 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
[jira] [Comment Edited] (SOLR-9546) There is a lot of unnecessary boxing/unboxing going on in {{SolrParams}} class
[
https://issues.apache.org/jira/browse/SOLR-9546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15511196#comment-15511196
]
Pushkar Raste edited comment on SOLR-9546 at 9/21/16 9:16 PM:
--
Got you.
I will fix the {{Long getLong(String param, Long def)}} method only. It is not
as bad as initially thought.
I don't even think that method is needed. Calling {{Long getLong(String
param)}} would do the same thing, won't it?
was (Author: praste):
Got you.
I will fix the {{Long getLong(String param, Long def)}} method only. It is not
as bad as initially thought
> 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
>
> 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
[jira] [Comment Edited] (SOLR-9546) There is a lot of unnecessary boxing/unboxing going on in {{SolrParams}} class
[
https://issues.apache.org/jira/browse/SOLR-9546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15511132#comment-15511132
]
Pushkar Raste edited comment on SOLR-9546 at 9/21/16 8:49 PM:
--
That was just one example. Check {{getBool()}}, {{getFieldBool()}} methods
those have the exact same problem, and there are many more.
I am not sure which way we should go (primitive vs Wrapped types) but I am
inclined towards primitive types.
was (Author: praste):
That was just one example check {{getBool()}}, {{getFieldBool()}} methods those
have the exact same problem, and there are many more.
I am not sure which way we should go (primitive vs Wrapped types) but I am
inclined towards primitive types.
> 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
>
> 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
