mirror of
https://github.com/prometheus/prometheus
synced 2024-12-26 00:23:18 +00:00
5b53aa1108
Wiser coders than myself have come to the conclusion that a `switch` statement is almost always superior to a statement that includes any `else if`. The exceptions that I have found in our codebase are just these two: * The `if else` is followed by an additional statement before the next condition (separated by a `;`). * The whole thing is within a `for` loop and `break` statements are used. In this case, using `switch` would require tagging the `for` loop, which probably tips the balance. Why are `switch` statements more readable? For one, fewer curly braces. But more importantly, the conditions all have the same alignment, so the whole thing follows the natural flow of going down a list of conditions. With `else if`, in contrast, all conditions but the first are "hidden" behind `} else if `, harder to spot and (for no good reason) presented differently from the first condition. I'm sure the aforemention wise coders can list even more reasons. In any case, I like it so much that I have found myself recommending it in code reviews. I would like to make it a habit in our code base, without making it a hard requirement that we would test on the CI. But for that, there has to be a role model, so this commit eliminates all `if else` occurrences, unless it is autogenerated code or fits one of the exceptions above. Signed-off-by: beorn7 <beorn@grafana.com>
71 lines
1.7 KiB
Go
71 lines
1.7 KiB
Go
// Copyright 2013 The Prometheus Authors
|
|
// Licensed under the Apache License, Version 2.0 (the "License");
|
|
// you may not use this file except in compliance with the License.
|
|
// You may obtain a copy of the License at
|
|
//
|
|
// http://www.apache.org/licenses/LICENSE-2.0
|
|
//
|
|
// Unless required by applicable law or agreed to in writing, software
|
|
// distributed under the License is distributed on an "AS IS" BASIS,
|
|
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
// See the License for the specific language governing permissions and
|
|
// limitations under the License.
|
|
|
|
package remote
|
|
|
|
import (
|
|
"sync"
|
|
"time"
|
|
|
|
"go.uber.org/atomic"
|
|
)
|
|
|
|
// ewmaRate tracks an exponentially weighted moving average of a per-second rate.
|
|
type ewmaRate struct {
|
|
newEvents atomic.Int64
|
|
|
|
alpha float64
|
|
interval time.Duration
|
|
lastRate float64
|
|
init bool
|
|
mutex sync.Mutex
|
|
}
|
|
|
|
// newEWMARate always allocates a new ewmaRate, as this guarantees the atomically
|
|
// accessed int64 will be aligned on ARM. See prometheus#2666.
|
|
func newEWMARate(alpha float64, interval time.Duration) *ewmaRate {
|
|
return &ewmaRate{
|
|
alpha: alpha,
|
|
interval: interval,
|
|
}
|
|
}
|
|
|
|
// rate returns the per-second rate.
|
|
func (r *ewmaRate) rate() float64 {
|
|
r.mutex.Lock()
|
|
defer r.mutex.Unlock()
|
|
return r.lastRate
|
|
}
|
|
|
|
// tick assumes to be called every r.interval.
|
|
func (r *ewmaRate) tick() {
|
|
newEvents := r.newEvents.Swap(0)
|
|
instantRate := float64(newEvents) / r.interval.Seconds()
|
|
|
|
r.mutex.Lock()
|
|
defer r.mutex.Unlock()
|
|
|
|
switch {
|
|
case r.init:
|
|
r.lastRate += r.alpha * (instantRate - r.lastRate)
|
|
case newEvents > 0:
|
|
r.init = true
|
|
r.lastRate = instantRate
|
|
}
|
|
}
|
|
|
|
// inc counts one event.
|
|
func (r *ewmaRate) incr(incr int64) {
|
|
r.newEvents.Add(incr)
|
|
}
|