lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noble Paul (JIRA)" <>
Subject [jira] [Commented] (SOLR-7110) Optimize JavaBinCodec to minimize string Object creation
Date Sun, 15 Feb 2015 15:06:11 GMT


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

> Optimize JavaBinCodec to minimize string Object creation
> --------------------------------------------------------
>                 Key: SOLR-7110
>                 URL:
>             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

This message was sent by Atlassian JIRA

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

View raw message