Slices of pointers or not?

234 views
Skip to first unread message

Paulo Júnior

unread,
Feb 3, 2022, 8:06:52 PM2/3/22
to golang-nuts
Hi all.

I hope you are well.

Is there a big difference, in terms of performance or functionality, between declaring []*Person or []Person as a return type of a function?


Thank you and best regards.
Paulo.

Marcin Romaszewicz

unread,
Feb 3, 2022, 8:20:32 PM2/3/22
to Paulo Júnior, golang-nuts
It depends on what you do with it, and how you use it.

[]*Person is a slice of pointers, they're small.
[]Person is a slice of structs, they're bigger than pointers.

The first requires a level of indirection to access, the second doesn't. The first requires no copying of structs when you're iterating or resizing, while the second requires copying entire structs.

So, either could be faster based on what you do with it.

--
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 golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/964eb09d-cd5f-4da1-b1ca-cac3e9b5bb69n%40googlegroups.com.

Robert Engels

unread,
Feb 3, 2022, 8:20:47 PM2/3/22
to Paulo Júnior, golang-nuts
No. Because a slice is a slice. But there are several performance differences in the usage. 

On Feb 3, 2022, at 7:09 PM, Paulo Júnior <pauloaf...@gmail.com> wrote:

Hi all.
--

Connor Kuehl

unread,
Feb 3, 2022, 9:04:12 PM2/3/22
to Paulo Júnior, golang-nuts
On Thu, Feb 3, 2022 at 7:07 PM Paulo Júnior <pauloaf...@gmail.com> wrote:
>
> Hi all.
>
> I hope you are well.
>
> Is there a big difference, in terms of performance or functionality, between declaring []*Person or []Person as a return type of a function?

If you find yourself iterating over a group of structs like this a lot
(especially if there's a lot of them to iterate over), you might want
to consider measuring the performance differences between []*Person or
[]Person. With pointers, the actual structs might be far away from
each other in memory, which may prevent you from taking full advantage
of your processor's cache since it won't be able to benefit from the
spatial locality that an array (or slice) offers.

Connor

Robert Engels

unread,
Feb 3, 2022, 10:12:47 PM2/3/22
to Connor Kuehl, Paulo Júnior, golang-nuts
I think the OPs question was specifically about the cost of returning from a function - it is the same.

> On Feb 3, 2022, at 8:03 PM, Connor Kuehl <cipk...@gmail.com> wrote:
> --
> 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 golang-nuts...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAC_QXZS-QEKTgvsK3TKk-yUyc1jP81HngHz6dcDV8bZwqLBT6Q%40mail.gmail.com.

Paulo Júnior

unread,
Feb 4, 2022, 4:43:28 AM2/4/22
to golang-nuts
I appreciate your help.

Amnon

unread,
Feb 6, 2022, 1:45:28 AM2/6/22
to golang-nuts
Go runtime is dominated by the costs of allocation and GC.

If you return 10000 persons, then if we make the (unrealistic) assumption that a Person contains not pointers (strings etc). then returning []Person would require one allocation, whereas returning []*Person would require 10,001. And GC will be much slower as there will be 10,000 more objects to mark.
Iteration across the returned slice will also be much faster in the former case, as each Person will
reside in (cache friendly) sequential memory locations, whereas in the latter case the memory location
of each person will be effectively randomised and entail a cache miss.

So in general returning []Person will be much faster. 
Of course you should make sure you pre-allocate the entire slice, rather than letting it grow automatically
as the result of appends.
Reply all
Reply to author
Forward
0 new messages