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