You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@beam.apache.org by "Thomas Groh (JIRA)" <ji...@apache.org> on 2016/10/27 16:37:58 UTC

[jira] [Updated] (BEAM-839) The DirectRunner slows down significantly as the number of keys increases

     [ https://issues.apache.org/jira/browse/BEAM-839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Groh updated BEAM-839:
-----------------------------
    Description: 
For example, running WordCount on KingLear takes approximately 10 seconds, while running WordCount on all of Shakespeare takes approximately 5 minutes. The primary cost is maintaining a PriorityQueue of Watermark Holds, which takes {{O(n**2)}} time, where {{n}} is the number of keys at a step.

Additionally, there are two other things that cause slowness. The first is use of UUID.randomUUID in the constructor of DelegatingAggregator, which uses a shared SecureRandom, which synchronizes on call to {{nextBytes(byte[])}}

  was:For example, running WordCount on KingLear takes approximately 10 seconds, while running WordCount on all of Shakespeare takes approximately 5 minutes. Most of this time is spent with the transforms unable to make progress, as the time is spent updating the minimum hold.


> The DirectRunner slows down significantly as the number of keys increases
> -------------------------------------------------------------------------
>
>                 Key: BEAM-839
>                 URL: https://issues.apache.org/jira/browse/BEAM-839
>             Project: Beam
>          Issue Type: Bug
>            Reporter: Thomas Groh
>            Assignee: Thomas Groh
>
> For example, running WordCount on KingLear takes approximately 10 seconds, while running WordCount on all of Shakespeare takes approximately 5 minutes. The primary cost is maintaining a PriorityQueue of Watermark Holds, which takes {{O(n**2)}} time, where {{n}} is the number of keys at a step.
> Additionally, there are two other things that cause slowness. The first is use of UUID.randomUUID in the constructor of DelegatingAggregator, which uses a shared SecureRandom, which synchronizes on call to {{nextBytes(byte[])}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)