[
https://issues.apache.org/jira/browse/PARQUET-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17454215#comment-17454215
]
ASF GitHub Bot commented on PARQUET-2106:
-----------------------------------------
alexeykudinkin commented on a change in pull request #940:
URL: https://github.com/apache/parquet-mr/pull/940#discussion_r763340453
##########
File path:
parquet-column/src/main/java/org/apache/parquet/schema/PrimitiveComparator.java
##########
@@ -183,10 +183,10 @@ public String toString() {
private static abstract class BinaryComparator extends
PrimitiveComparator<Binary> {
@Override
int compareNotNulls(Binary o1, Binary o2) {
- return compare(o1.toByteBuffer(), o2.toByteBuffer());
+ return compareBinary(o1, o2);
}
- abstract int compare(ByteBuffer b1, ByteBuffer b2);
+ abstract int compareBinary(Binary b1, Binary b2);
Review comment:
The `Binary` refers to a class not an object, hence it feels more
natural as `compareBinary`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
> BinaryComparator should avoid doing ByteBuffer.wrap in the hot-path
> -------------------------------------------------------------------
>
> Key: PARQUET-2106
> URL: https://issues.apache.org/jira/browse/PARQUET-2106
> Project: Parquet
> Issue Type: Task
> Components: parquet-mr
> Affects Versions: 1.12.2
> Reporter: Alexey Kudinkin
> Priority: Major
> Attachments: Screen Shot 2021-12-03 at 3.26.31 PM.png,
> profile_48449_alloc_1638494450_sort_by.html
>
>
> *Background*
> While writing out large Parquet tables using Spark, we've noticed that
> BinaryComparator is the source of substantial churn of extremely short-lived
> `HeapByteBuffer` objects – It's taking up to *16%* of total amount of
> allocations in our benchmarks, putting substantial pressure on a Garbage
> Collector:
> !Screen Shot 2021-12-03 at 3.26.31 PM.png|width=828,height=521!
> [^profile_48449_alloc_1638494450_sort_by.html]
>
> *Proposal*
> We're proposing to adjust lexicographical comparison (at least) to avoid
> doing any allocations, since this code lies on the hot-path of every Parquet
> write, therefore causing substantial churn amplification.
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
