On Sunday, May 16, 2021 at 4:46:44 AM UTC-4 Brian Candler wrote:
> On Sunday, 16 May 2021 at 08:07:17 UTC+1 tapi...@gmail.com wrote: > >> > you don't provide memory allocation statistics, >> >> There are no surprises in memory allocation statistics so I didn't >> mention them. >> >> > I think it is relevant, because your different functions return slices of > different capacity (i.e. different amounts of memory allocated): > https://play.golang.org/p/3IQzd6J1ADa > > The only functions which allocate exactly the right size of slice are > InsertVerbose and InsertVerbose_b. The others rely on append(), and when > that exceeds the size of the current slice and has to allocate a new one, > it allocates a bit extra space for growing room. > > Therefore, you could be measuring boundary conditions around the size that > append() decides to round your slice up to, combined with amount of garbage > collection overhead for large values of N. > > Aside: larger values like N = 1615119 end up with SIGKILL in the > playground - presumably using too much memory - but run locally: > > ======== N = 1615119 > InsertOneline: cap=2524160 > InsertOneline_Disassemble: cap=2524160 > InsertVerbose: cap=2422678 > InsertVerbose_b: cap=2422678 > InsertVerbose_c: cap=2422784 > I'm aware of this. So I expect that the append implementations (especially the one-line ones) should be slower than InsertVerbose and InsertVerbose_b. This is just a small reason why the one-line implementations should be slower. The main reason is they both allocate twice. The expectation is promised from small Ns, but the benchmarks show it is broken for large Ns. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/29b99aae-2041-48a9-824c-f58fcd05ae02n%40googlegroups.com.
