Inline cost is part of how Go decides what funcs to inline. There are some
interesting patterns (maybe even idioms?) in Go that specifically try to
inline a lot of code to prevent values from escaping to the heap when they
don't have to. Concrete examples from -gcflags='-m -m':
./main.go:7:6: can inline fooCompositeLiteral with cost 3 as: func() { _ =
Version{} }
./main.go:11:6: can inline fooCompositeLiteralP with cost 4 as: func() { _
= &Version{} }
./main.go:15:6: can inline fooNew with cost 4 as: func() { _ =
*new(Version) }
./main.go:19:6: can inline fooNewP with cost 3 as: func() { _ =
new(Version) }
In a tight spot, that 1 cost might make a drastic difference.
On Monday, March 17, 2025 at 11:39:19 PM UTC-7 Dan Kortschak wrote:
> On Mon, 2025-03-17 at 21:03 -0700, [email protected] wrote:
> > I prefer *new(T) over T{}, because not only the reason here, but also
> > the former has a smaller inline cost.
>
> What do you mean by "inline cost"?
>
> https://godbolt.org/z/h8Krq7W8G
>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/golang-nuts/8d0d8027-a661-4fe6-882b-7a799903a80bn%40googlegroups.com.
