[
https://issues.apache.org/jira/browse/TEZ-2731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14706228#comment-14706228
]
Rajesh Balamohan commented on TEZ-2731:
---------------------------------------
lgtm. +1.
Had it been uncontended synchronization UseBiasedLocking (believe this is
enabled in default in JDK 7) would have been triggered and not seen this level
of drop in perf with sync. But appears that it is relatively contended with
less threads in which case atomic long help a lot in improving the perf.
> Fix Tez GenericCounter performance bottleneck
> ---------------------------------------------
>
> Key: TEZ-2731
> URL: https://issues.apache.org/jira/browse/TEZ-2731
> Project: Apache Tez
> Issue Type: Sub-task
> Affects Versions: 0.6.0, 0.7.0, 0.8.0
> Reporter: Gopal V
> Assignee: Gopal V
> Attachments: TEZ-2731.1.patch, atomic-long-cntr.png, lock-inc.png,
> mr-reader-next.png
>
>
> GenericCounter::increment(1) shows up as a ~16% performance penalty inside
> the unvectorized codepath of Hive queries.
> The vectorized codepath amortizes this entirely by running through that
> exactly once every 1024 rows & the performance improvement is dramatic.
> !lock-inc.png!
> !mr-reader-next.png!
> Optimize the GenericCounter impl for mostly uncontested atomic operations.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
