[
https://issues.apache.org/jira/browse/SOLR-7110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14322012#comment-14322012
]
Noble Paul commented on SOLR-7110:
----------------------------------
bq. Is this change back-compatible?
Yes, There is no change to the serialization format. Only the deserialization
logic is changed
bq.This isn't unique to JavaBin either... one could use the same technique in
any of our transports (including HTTP params).
Yes. The good part about javabin is possibly repeated strings are written as a
different type in javabin . In other payloads we need to identify what is the
'cacheable' string
bq.The extra work + overhead of our concurrent LRU cache should swamp any
savings. Has this been benchmarked?
I plan to do the benchmark. My hunch is that performance will be similar , a
map.get() cannot be far more expensive than an Object creation and subsequent
GC.
Even if the performance is same this helps a lot on cutting down String objects
and hence GC
> Optimize JavaBinCodec to minimize string Object creation
> --------------------------------------------------------
>
> Key: SOLR-7110
> URL: https://issues.apache.org/jira/browse/SOLR-7110
> Project: Solr
> Issue Type: Improvement
> Reporter: Noble Paul
> Assignee: Noble Paul
> Priority: Minor
> Attachments: SOLR-7110.patch
>
>
> In JavabinCodec we already optimize on strings creation , if they are
> repeated in the same payload. if we use a cache it is possible to avoid
> string creation across objects as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
