lostluck commented on a change in pull request #11231: [BEAM-4374] Shortids for
the Go SDK
URL: https://github.com/apache/beam/pull/11231#discussion_r398886664
##########
File path: sdks/go/pkg/beam/core/runtime/harness/monitoring.go
##########
@@ -16,20 +16,71 @@
package harness
import (
+ "bytes"
+ "strconv"
+ "sync"
+ "sync/atomic"
"time"
+ "github.com/apache/beam/sdks/go/pkg/beam/core/graph/coder"
+ "github.com/apache/beam/sdks/go/pkg/beam/core/graph/mtime"
"github.com/apache/beam/sdks/go/pkg/beam/core/metrics"
"github.com/apache/beam/sdks/go/pkg/beam/core/runtime/exec"
fnpb "github.com/apache/beam/sdks/go/pkg/beam/model/fnexecution_v1"
ppb "github.com/apache/beam/sdks/go/pkg/beam/model/pipeline_v1"
"github.com/golang/protobuf/ptypes"
)
-func monitoring(p *exec.Plan) (*fnpb.Metrics, []*ppb.MonitoringInfo) {
+// TODO: 2020/03/26 - measure mutex overhead vs sync.Map for this case.
+// sync.Map might have lower contention for this read heavy load.
+var (
+ shortMu sync.Mutex
+ labels2ShortIds map[metrics.Labels]string
Review comment:
Ah good point.
Can't use protos as Go Map keys, because of all the magic fields they have,
but I can use other things.
I've put in aligned constants, types, and string arrays for the proto
specified strings, so these lookups don't end up hashing the strings every time
(and instead use a uint32, which is very fast for go maps to deal with.)
There's still the hashing of the fields in metrics.Labels, but we can do the
same hashing in the metrics code at a later time, to allow for faster lookups
for those instead.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
