2 ms·
> performance regression What? Golang append()s also periodically grow the slice. > Conditional logic it's just a single if, really, the same thing is there
by porridgeraisin 2y ago
> performance regression
What? Golang append()s also periodically grow the slice.
> Conditional logic
it's just a single if, really, the same thing is there in your filter()
> Multiple layers of nesting
2... You're talking it up like it's a pyramid of hell. For what it's worth, I've seen way way more nesting in usual FP-style code, especially with formatting tools doing
func(
args
)
For longer elements of the function chain.
- stouset 2y ago> What? Golang append()s also periodically grow the slice. If you already know the size of the result (there are no filtering operations), the functional approach can trivially allocate the resulting array to already have the correct capacity. This happens with zero user intervention. IIRC the Rust optimizer basically emits more or less optimal machine code (including SIMD) for most forms of iteration.
- porridgeraisin 2y agoWe are talking about making an array with unique elements here. You cannot know the correct capacity for that without overallocating. If overallocating is indeed OK for your usecase, then you can do so yourself uniq := make([]MyObject, 0, len(my_objects))
- stouset 2y agoI was talking more in the general case. Yes, you can always just write more and more and more code to fix these things. Or you could just… not write more code and still get optimal performance.
- porridgeraisin 2y ago> just... Not write more code But the abstractions don't really adapt themselves to be performant in each usecase the way you imagine. I gave an example of c# distinct() above. Sure, they can. But do they? No. They only save anything at all for trivial usecases, where the imperative code is also obvious to parse.