You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@spark.apache.org by "Sean Owen (JIRA)" <ji...@apache.org> on 2016/09/09 19:33:21 UTC
[jira] [Commented] (SPARK-17480) CompressibleColumnBuilder
inefficiently call gatherCompressibilityStats
[ https://issues.apache.org/jira/browse/SPARK-17480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15478035#comment-15478035 ]
Sean Owen commented on SPARK-17480:
-----------------------------------
Yeah, I wonder if the "unrolled" while loop here is really the right way to do it. You can certainly solve the problem by just computing the length once, but, I don't really see why {{compressionEncoders.foreach(_.gatherCompressibilityStats(row, ordinal))}} isn't just simpler and probably no different performance-wise.
> CompressibleColumnBuilder inefficiently call gatherCompressibilityStats
> ------------------------------------------------------------------------
>
> Key: SPARK-17480
> URL: https://issues.apache.org/jira/browse/SPARK-17480
> Project: Spark
> Issue Type: Improvement
> Components: SQL
> Reporter: Ergin Seyfe
> Priority: Minor
>
> When we profile one of our Spark jobs we saw that:
> 6.24% of the CPU is spend on List.length.
> Scala List's length method is O(N) => https://github.com/scala/scala/blob/2.10.x/src/library/scala/collection/LinearSeqOptimized.scala#L36
> Since we loop this method becomes O(N^2)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@spark.apache.org
For additional commands, e-mail: issues-help@spark.apache.org