[ 
https://issues.apache.org/jira/browse/BEAM-4468?focusedWorklogId=202879&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-202879
 ]

ASF GitHub Bot logged work on BEAM-4468:
----------------------------------------

                Author: ASF GitHub Bot
            Created on: 22/Feb/19 21:18
            Start Date: 22/Feb/19 21:18
    Worklog Time Spent: 10m 
      Work Description: lostluck commented on issue #7927: [BEAM-4468] Go SDK 
Combiner Optimizations
URL: https://github.com/apache/beam/pull/7927#issuecomment-466551156
 
 
   I'm pulling back the invocation optimization since there's something I'm 
missing there.
   
   Run Go PostCommit
 
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
[email protected]


Issue Time Tracking
-------------------

    Worklog Id:     (was: 202879)
    Time Spent: 1h  (was: 50m)

> Go SDK-Tune in memory pre-combine caching for Lifted Combines.
> --------------------------------------------------------------
>
>                 Key: BEAM-4468
>                 URL: https://issues.apache.org/jira/browse/BEAM-4468
>             Project: Beam
>          Issue Type: Improvement
>          Components: sdk-go
>            Reporter: Robert Burke
>            Assignee: Robert Burke
>            Priority: Minor
>          Time Spent: 1h
>  Remaining Estimate: 0h
>
> Requires [BEAM-4276|https://issues.apache.org/jira/browse/BEAM-4276] to be 
> completed first.
> Additional performance tweaks to the in memory per-key accumulator cache 
> during the pre-combine phase of a lifted combine.
> This can include any of
>  * capping the number of key-accumulator in the cache, and draining them 
> eagerly after x elements seen, or evicting keys by some heuristic after the 
> cache has seen X distinct keys.
>  * providing a counter on cache size (key/element counts) exposable through 
> the metrics interface or another runner standard counter, to permit observing 
> the cache's status, especially if it could grow without bound within a bundle.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to