On Tue, Oct 10, 2017 at 12:50 AM, Gabriel Aszalos
<gabriel.asza...@gmail.com> wrote:
>
> I would love to find out the answer to this. Even if you don't know the
> answer but know how to investigate into it (using pprof or some tracing
> flags), I would also appreciate being guided in the right direction and I
> would love to embark on the journey of finding out myself.
>
> What I'm basically saying is that I'd be more interested to find out the way
> in which I can tell why one is faster than the other, as opposed to hearing
> just the final answer. Hope that makes sense.

Start by writing a standalone x_test.go program that provides both
versions of the code and uses the benchmark framework to measure both.
When you can repeat the issue with -bench=., run it with -benchmem to
print the memory allocations.  If they are different, that is probably
the cause.  Then you have to figure out why they are different.  If
they are not different, you'll need to look at the generated code.  On
GNU/Linux, the system's perf tool can help you identify which parts of
the code take more time.  For a larger program I would suggest pprof,
but pprof is better at pointing you at a specific function then it is
at identifying which part of the function is slow.

Ian


> On Thursday, 5 October 2017 15:22:47 UTC+2, Marvin Stenger wrote:
>>
>> I can reproduce the numbers. The only think I'm seeing is that the spans
>> array is allocated on the stack. Not sure though if this is the only reason.
>>
>> Am Donnerstag, 5. Oktober 2017 13:13:56 UTC+2 schrieb Gabriel Aszalos:
>>>
>>> I was playing around with the implementation of FieldsFunc from the bytes
>>> package and I was wondering how it would affect the benchmarks to disregard
>>> the extra slice that was used there to calculate offsets. It only made sense
>>> that it would make things faster.
>>>
>>> To my amusement (although expected), it didn't. But I'm quite curious why
>>> one is faster than the other and if this reveals any good practices when
>>> working with similar algorithms. The benchmark and diff I am talking about
>>> can be viewed here:
>>>
>>>
>>> https://github.com/gbbr/go/commit/2f6e92bc746fa232f2f2aea66dae3fa0c04700a5?diff=split
>>>
>>> Many thanks for looking!
>>
>>
> --
> 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.

Reply via email to