[
https://issues.apache.org/jira/browse/SOLR-272?page=com.atla
ssian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Yonik Seeley updated SOLR-272:
------------------------------
Attachment: SolrDocumentPerformanceTester.java
Attraching the modified test prog I used.
I modified it to accept separate counts, and do separate
runs for the different implementations.
For example, 100000 0 0 and 0 0 10000
This was to avoid any GC effects from one implementation to
another, and to avoid hotspot optimizing for one path and
then having a different implementation switch to a different
path.
The SolrInputDocument builder also needed that change from
setField to addField to be equivalent.
> SolrDocument performance testing
> --------------------------------
>
> Key: SOLR-272
> URL: https:
//issues.apache.org/jira/browse/SOLR-272
> Project: Solr
> Issue Type: Test
> Affects Versions: 1.3
> Reporter: Ryan McKinley
> Attachments:
SOLR-272-SolrDocumentPerformanceTesting.patch,
SOLR-272-SolrDocumentPerformanceTesting.patch,
SolrDocumentPerformanceTester.java,
SolrDocumentPerformanceTester.java, SolrInputDoc.patch
>
>
> In 1.3, we added SolrInputDocument -- a temporary class
to hold document information. There is concern that this
may be less then ideal performance-wise.
> To settle some concerns (mine included) I want to
compare a few SolrDocument implementations to make sure we
are not doing something crazy.
> I implemented a LuceneInputDocument subclass of
SolrInputDocument that stores its values directly in Lucene
Document (rather then a Map<String,Collection>).
> This is a quick test comparing:
> 1. Building documents with SolrInputDocument
> 2. Building documents with LuceneInputDocument (same
interface writing directly to Document)
> 3. using DocumentBuilder (solr 1.2, solr 1.1)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue
online.
|
