[ https://issues.apache.org/jira/browse/KAFKA-6168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16265861#comment-16265861
]
Ted Yu commented on KAFKA-6168:
-------------------------------
bq. it might be worth considering having each instance precompute and cache a string or byte[]
representation
[~ewencp]:
Do you think the above is worth doing for keySchema and valueSchema fields ?
> Connect Schema comparison is slow for large schemas
> ---------------------------------------------------
>
> Key: KAFKA-6168
> URL: https://issues.apache.org/jira/browse/KAFKA-6168
> Project: Kafka
> Issue Type: Improvement
> Components: KafkaConnect
> Affects Versions: 1.0.0
> Reporter: Randall Hauch
> Assignee: Ted Yu
> Priority: Critical
> Fix For: 1.1.0
>
> Attachments: 6168.v1.txt
>
>
> The {{ConnectSchema}} implementation computes the hash code every time its needed, and
{{equals(Object)}} is a deep equality check. This extra work can be expensive for large schemas,
especially in code like the {{AvroConverter}} (or rather {{AvroData}} in the converter) that
uses instances as keys in a hash map that then requires significant use of {{hashCode}} and
{{equals}}.
> The {{ConnectSchema}} is an immutable object and should at a minimum precompute the hash
code. Also, the order that the fields are compared in {{equals(...)}} should use the cheapest
comparisons first (e.g., the {{name}} field is one of the _last_ fields to be checked). Finally,
it might be worth considering having each instance precompute and cache a string or byte[]
representation of all fields that can be used for faster equality checking.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
|