When the python functions are actually called the comparison is more reasonable:
``` ~/concat $ go test -bench . concat_test.go BenchmarkUnicodeConcat-8 200000 10379 ns/op PASS ok command-line-arguments 2.193s ~/concat $ python concat_test.py time_taken = 8901.3030529 nsec ~/concat $ python3 concat_test.py time_taken = 7210.201049922034 nsec ``` This involved appending "; concat()" and "; mysetup()" to the stmt and setup parameters. On Mon, 2017-02-27 at 19:03 -0800, Ian Lance Taylor wrote: > On Mon, Feb 27, 2017 at 6:40 PM, Shubha Ramani <shubharam...@gmail.co > m> wrote: > > > > mysetup is being called here: > > > > times = timeit.Timer(stmt="from __main__ import > > concat",setup="gc.enable();from __main__ import > > mysetup").repeat(7,loops) > > > > Look at "from __main__ import mysetup" after gc.enable(); > > gc,enable() > > according to timeit rules needs to be called > > before the setup function. Are you saying Ian that I only import > > but never > > call mysetup() ? Perhaps you are right but I followed examples and > > this is > > what I thought was correct (maybe not). > I added print statements to the Python functions and they never > printed. I don't know whether that proves anything or not. > > Your micro-benchmarks are suspicious because they don't exist. It > would take very little for the compiler to simply discard all the > computation. I'm actually surprised that does not happen with the Go > compiler--seems like a minor bug. I wonder whether the Python > interpreter is doing that one way or another. > > You should always write a micro-benchmark to compute a real result > and > verify that the result is what you expect. Otherwise a clever > compiler will completely defeat the purpose of the benchmark. > > Ian > -- 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.
