Filtering a slice by worth vs reference – Getting Assist

I’ve an “occasion” struct that incorporates a slice of period structs. I must filter out the durations which might be expired, or have already occurred.

The use-case is in a really high-traffic micro service working gin. It’s not user-facing, however is consumed by a user-facing restful API service. I count on that these slices may have not far more than, say, 20 parts, and every request might have about 20 occasions structs.

I’m unsure, given the use case, if within the instance the place I move by reference, and leverage the slice’s underlying array is worth it by way of reminiscence footprint. The instance the place I move by worth and allocate a brand new array for the filtered durations is easier to learn and possibly much less error inclined. I notice that the structs within the slice are light-weight, given they’re simply ints.

The query is whether or not in my use-case the financial savings in reminiscence is worth it, on condition that the the server is excessive visitors. I’m unsure given the anticipated dimension of the information and the truth that it’s in a server context that passing by reference and re-using the underlying array is worth it. There’s additionally the problem of constant API. Let’s say that the occasions have extra sophisticated knowledge, and I count on to do a number of steps of post-processing, filtering on different properties and many others and thus very effectively might add different capabilities that do related issues. I’m not a lot fretting over each little bit of reminiscence, but it surely’s the primary time I’ve used a language with pointers in manufacturing code. Ideas?

Instance:
playground

package deal principal

import "fmt"

sort period struct {
	ValidFrom  int64
	ValidUntil int64
}
sort occasion struct {
	Recurrences []period
}

func filterExpired(evt occasion, now int64) occasion {
	var recurrences []period
	for _, r := vary evt.Recurrences {
		if r.ValidUntil >= now {
			recurrences = append(recurrences, r)
		}
	}
	evt.Recurrences = recurrences
	return evt
}
func filterExpired2(evt *occasion, now int64) {
	// Take a zero-length slice of the underlying array.
	temp := evt.Recurrences[:0]
	for _, r := vary evt.Recurrences {
		if r.ValidUntil >= now {
			temp = append(temp, r)
		}
	}
	evt.Recurrences = temp
}

func principal() {
	evt1 := occasion{Recurrences: []period{{ValidFrom: 100, ValidUntil: 200}, {ValidFrom: 250, ValidUntil: 300}}}
	fmt.Println(filterExpired(evt1, 201))
	evt2 := occasion{Recurrences: []period{{ValidFrom: 100, ValidUntil: 200}, {ValidFrom: 250, ValidUntil: 300}}}
	filterExpired2(&evt2, 201)
	fmt.Println(evt2)
}

I’d go together with your intuition of making a brand new slice till GC stress turns into an actual drawback. You even point out the probability of a number of filtering steps. That may positively complicate reusing the slice in case your a number of steps run concurrently.

Not Go, however a lot earlier in my profession I spent many lengthy days debugging from core dumps errors attributable to manipulating pointers. Now I do something I can to provide code that’s appropriate now and resilient to modifications sooner or later.

I’m additionally conflating passing by reference and never allocating an additional array. Each of which aren’t crucial on this context so far as I can inform.

one thing like this?

func filterExpired3(evt *occasion, now int64) {
	newSize := 0
	for i := 0; i < len(evt.Recurrences); i++ {
		if evt.Recurrences[i].ValidUntil >= now {
			if newSize != i {
				evt.Recurrences[newSize] = evt.Recurrences[i]
			}
			newSize++
		}
	}
	evt.Recurrences = evt.Recurrences[:newSize]
}

I’m confused that it might similar as “var recurrences []period”，and there’s one factor simply misunderstood in Golang. the place you move worth ( slice or map ) as param , it all the time move by reference, no matter you employ “evt occasion” or “evt *occasion”