[
https://issues.apache.org/jira/browse/SOLR-14013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16989121#comment-16989121
]
Yonik Seeley commented on SOLR-14013:
-------------------------------------
I did some digging... the current code is certainly more complex than it used
to be.
So for a multi-valued field, the values internally are now IndexableField (for
each value)
For each of those values, we call JavaBinCodec.writeVal
which tries writeKnownTypes
which tests if it's a member of ~10 primitive types via instanceof
failing, then tests against 19 other types
failing, falls back to object resolver which tries against 4 other types,
finally matching it up to IndexableField
the schema is used to look up the SchemaField based on name (2 more hash
lookups)
then we call DocStreamer.getValue(), which does another hash lookup based on
the .getClass()
and then calls FieldType.toObject() which calls toExternal() which finally
calls stringValue() on the IndexableField
and now that we have our object, JavaBinCodec can try writeKnownTypes() again
And this is now the common case!
> javabin performance regressions
> -------------------------------
>
> Key: SOLR-14013
> URL: https://issues.apache.org/jira/browse/SOLR-14013
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Affects Versions: 7.7
> Reporter: Yonik Seeley
> Assignee: Yonik Seeley
> Priority: Major
> Attachments: test.json
>
>
> As noted by [~rrockenbaugh] in SOLR-13963, javabin also recently became
> orders of magnitude slower in certain cases since v7.7. The cases identified
> so far include large numbers of values in a field.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
