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

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

                Author: ASF GitHub Bot
            Created on: 22/Feb/19 22:19
            Start Date: 22/Feb/19 22:19
    Worklog Time Spent: 10m 
      Work Description: lostluck commented on issue #7927: [BEAM-4468] Go SDK 
Combiner Lifting cache cap & eviction.
URL: https://github.com/apache/beam/pull/7927#issuecomment-466566397
 
 
   Good catch! Thanks! I've added it to my next commit, for the now-separated 
invokers PR, as that should be worth 10-15% overhead.
 
----------------------------------------------------------------
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: 202906)
    Time Spent: 1h 40m  (was: 1.5h)

> 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 40m
>  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