The point is, that (as repeatedly pointed out) microbenchmarks just, in general, don't tell you anything really useful, as any effects you measure could be due to anything ranging from random noise, over compiler optimizations to code-alignments. Avoiding type assertions based on anything contained in this thread is pretty unreasonable; I see zero evidence here, that they are, at all, a problem.
Go gives you pretty amazing tools to find the actual bottlenecks in your code. Again: Write your code as it's most convenient, then run it with production data on production hardware and *if* it isn't fast enough, use pprof and similar tools to find the actual bottlenecks. They very likely won't be type-assertions. On Thu, Feb 2, 2017 at 5:16 PM, Jan Ziak <0xe2.0x9a.0...@gmail.com> wrote: > A large difference between an implementable highly-optimized run-time > performance of feature X and the physically implemented run-time > performance of feature X causes programmers to avoid X. > > On Thursday, February 2, 2017 at 3:32:16 PM UTC+1, Marvin Renich wrote: >> >> * Marvin Renich <mr...@renich.org> [170202 09:22]: >> > >> > BenchmarkIface is testing the wrong thing; the value is swamped by the >> > implicit conversion of d (type T) to the function argument of type I. >> >> Or, maybe it is testing the correct thing. That is the problem with >> microbenchmarking. Try benchmarking your actual code instead. :-P >> >> ...Marvin >> >> -- > 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. > For more options, visit https://groups.google.com/d/optout. > -- 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. For more options, visit https://groups.google.com/d/optout.
