Well you're waiting in the select... so yeah its going to be at the top. The tickers themselves take up quite a bit of resources, in a little test like this.
I adjusted your test to remove all the tickers, and got about 4x the speed.
I also set GOMAXPROCS to 1 gives it a better case against node. I made the
cpuprofile flag controlled. Then also ran the tests descending, to see if
being "warm" did anything.
I attached the changes if you want to try them out. The tickers were the
real hogs. On my vm the times look like
1 69.655702ms
2 122.78818ms
3 149.580323ms
4 158.053242ms
5 153.452385ms
6 200.548673ms
5 160.500261ms
4 134.539412ms
3 117.446786ms
2 125.365ms
1 132.77861ms
-Chris
On Sunday, February 5, 2017 at 11:00:15 AM UTC-8, fwan...@gmail.com wrote:
>
> I make a test to see the performance of select, and found the result is
> not good.
>
> I make 1000 SeqQueue objects and run its messageLoop function (which does
> a small piece of work, and is listed as below) in 1000 separate go
> routines. The CPU cost is more than 20%.
> If I make the ticker 1 second, the CPU cost can slow down to about 2%.
>
> With pprof, I see the most top cost are methods related to
> runtime.selectGo, runtime.lock.
>
> Who knows is there anything wrong in my case?
>
> func (this *SeqQueue) messageLoop() {
> var ticker = time.NewTicker(100 * time.Millisecond)
> defer ticker.Stop()
> for {
> select {
> case <-serverDone:
> return
> case <-this.done:
> return
> case <-ticker.C:
> this.tickCounter += 1
> case message := <-this.messages:
> this.messageCounter += 1
> _ = message
> }
> }
> }
>
>
>
>
--
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.
waitcond.go
Description: Binary data
test.go
Description: Binary data
