FWIW I did take a look at the output (I ended up curious enough): https://go.godbolt.org/z/WK8xYd1E3
Insert and Insert2 generate pretty different code. In particular, Insert2 uses makeslicecopy, to fold the `make` and the `copy(s2, a)` (avoiding having to zero the relevant memory). `Insert` uses makeslice and a memmove for the `copy(s2, s[:k])`. I assume that's because the compiler can easily prove that `len(s2) == len(a)+len(b)+len(c) > len(a)`, therefore it sees that the `copy` actually copies all of `a`. For `Insert`, it needs to do extra bounds checks. So, looking at this output might've answered your question before posting it. It certainly would've provided helpful context for anyone trying to explain the behavior who isn't a domain expert in how the compiler optimizes things like this. i.e. it certainly would've increased the likelihood that any questions remaining *will* get an answer. On Thu, Jul 29, 2021 at 8:08 AM Axel Wagner <axel.wagner...@googlemail.com> wrote: > It would have taken you less time to look at the generated code and/or a > CPU profile than it would have to post this - let alone the rest of the > discussion. I also believe it likely would take more time to type out the > answer to your question, than it would for you to look at the generated > code and/or a CPU profile. So no, I reject your reasoning that this is more > convenient. Even *if* it saves time in absolute terms (i.e. even *if* > someone can send an answer faster than you could do these most basic > checks), it's still a tradeoff between taking up *your* time and taking up > *their* time. It's still rude. > > I also reject your reasoning that "golang-nuts is for communication". > There are clear and written limitations on that (in the form of the CoC) > and also unwritten limitations (otherwise we'd get constant > recruiter-spam). If multiple people ask you to do a bit more research > yourself before asking these questions, it's an indicator that you are > stepping closer to these unwritten limitations. You should at least take > them seriously. > > Lastly, it's, again, not like your questions are not *interesting*. I'd > likely want to read about them, based on the topic. I'm generally > interested in optimizations and compiler internals. But I would prefer them > to be pre-filtered to actual conundrums, instances where I can reasonably > help or learn something new. So, IMO, it would also be in your best > interest to do this. Not only do you learn more about investigating these > things, you also will likely increase the usefulness of the answers, if > people *don't* just discard your message as "oh, it's one of these again". > > Anyways. To repeat this one last time: I'd respectfully ask you to conduct > a little bit more reasearch on your own, before sending these mails. Namely > look at the generated code (the Compiler Explorer > <https://go.godbolt.org/> makes this really simple) and look at the > relevant profiling information (this blog post > <https://blog.golang.org/pprof>, while a little dated, still gives a good > intro). I genuinely think this is more helpful advice than trying to answer > your question. > > On Thu, Jul 29, 2021 at 5:24 AM tapi...@gmail.com <tapir....@gmail.com> > wrote: > >> >> >> On Wednesday, July 28, 2021 at 10:42:58 PM UTC-4 Kurtis Rader wrote: >> >>> On Wed, Jul 28, 2021 at 7:24 PM tapi...@gmail.com <tapi...@gmail.com> >>> wrote: >>> >>>> I will when I confirm that no one could give an answer without much >>>> effort. If you feel frustrated, you can ignored it. ;D >>>> >>> >>> Like Axel, I too am mildly annoyed by your questions. Primarily because >>> you don't seem to understand that the Go community isn't your private >>> unpaid research team and every time you start one of these threads you omit >>> important facts. Also, you don't seem to understand why things like the CPU >>> architecture, cache line size, L1 & L2 cache sizes, and similar factors are >>> frequently significant for the types of questions you keep asking. Frankly, >>> as Axel pointed out, you should be figuring out the answer and sharing your >>> findings with the community. >>> >> >> The go-nuts community is for communicating, right? >> I think it is not hard to ignore the uninterested topics. >> >> I will figure out the answer with as less effort as possible. >> If someone happens knows the answer, I'm very appreciated. >> If no one could give a confirmed answer, then I will seek other routes. >> >> >>> >>> -- >>> Kurtis Rader >>> Caretaker of the exceptional canines Junior and Hank >>> >> -- >> 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/74c0a27f-0e3e-4ee6-937b-67bf36dd8ae2n%40googlegroups.com >> <https://groups.google.com/d/msgid/golang-nuts/74c0a27f-0e3e-4ee6-937b-67bf36dd8ae2n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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/CAEkBMfGosX8oCp51NTJpO4_hPo4rcYMNrj_JK%2BRhKsFwaP%2B0LA%40mail.gmail.com.
