y, 22 November 2016 19:30:55 UTC+8, Dave Cheney wrote:
>
> The cgo call is going to cost you a lot more than this. Can you write up
> your real code and profile it.
>
> On Tuesday, 22 November 2016 22:11:34 UTC+11, Cia wrote:
>>
>>
>>
>> On Tuesday, 22 Nov
On Tuesday, 22 November 2016 18:51:46 UTC+8, Dave Cheney wrote:
>
> Why do you want to use LockOSthread, you've proved it has a significant
> performance cost for your application.
*Cgo* is the answer.
(Actually I want to use a C library(which needs LockOSthread to reach local
constant
On Tuesday, 22 November 2016 18:08:37 UTC+8, Dave Cheney wrote:
>
> Related, you don't need a pointer to a chan, channels are already pointers
> to the private runtime channel type.
Thanks for telling me that ☺ The codes will be pretty cleaner without the
pointer '*' notation.
Is there somet
On Tuesday, 22 November 2016 18:06:50 UTC+8, Dave Cheney wrote:
>
> Perf record / report will highlight the problem.
Thanks Dave.And here is the output of the perf report:
Samples: 48K of event 'cpu-clock', Event count (approx.): 1202025
Overhead Command Shared Object Symbol
59.40
On Tuesday, 22 November 2016 17:46:18 UTC+8, Dave Cheney wrote:
>
> Please try profiling your application, if you are on Linux perf(1) works
> very well for tracing user and system time.
Thanks for mention that :)
Here is the first step result of *perf stat*:
Performance counter stats for
Sorry :) This a mistake here:
> It's perf output is about 1000,000 ops/sec :)
>
> But when you uncomment the runtime.LockOSThread() at line 24(the beginning
> at func call_srv),it goes so slow to *100,000/sec* and the cpu usage of
> kernel goes into madness.
>
>
Actually it should be 100,000 o
Here is the minimal test case 0:
package main
import "fmt"
import "runtime"
type callRet struct {
ret int
}
type callIn struct {
ret_chan *chan *callRet
arg1 int
}
func caller(call_in_c *chan *callIn, arg1 int) int {
ret_c := make(chan *callRet)
ci := callIn{&ret_c
