On Wednesday, February 8, 2017 at 12:25:35 AM UTC-8, fwan...@gmail.com
wrote:
>
> If I use GOMAXPROCS=1, the result is acceptable.
>
Here are some more tests. This is scaling with number of cores, I assume
the slowdown is scheduler overhead, not really select cases.
2 core 2.4ghz VM
GOMAXPR
If I use GOMAXPROCS=1, the result is acceptable.
--
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
my test in machine of 12core*2.0G
before(use foo8.go):
1 2.305055967s
2 3.963565786s
3 3.909725761s
4 4.108974638s
5 4.209743812s
6 4.495325926s
cpu: 38-45%
after(use waitcond.go):
1 2.879277251s
2 2.804899636s
3 2.769632181s
4 2.884387569s
5 2.870019995s
6 2.822770813s
5 2.827548132s
4 2.877626
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 nod
I know the compare to nodejs doesn't mean anything because of different
mechanism.
I just want to find out what is the best way to use select, specially in a
for loop.
And in my messageLoop case, perhaps I have to reduce the number of channels
in the select, and make multiple kind of events ro
A few remarks:
1/ If you want to compare to node.js, please remove the CPU profiling
option from the go program - it comes with some overhead.
2/ The comparison is not really fair.
node.js implements a unique event loop (everything runs on the same thread).
Go generally schedules the goroutines
Seems for me, you don't do any selection like in JS code, even any
polling. Sure it would perform better. (Maybe I'm missing something, not
so proficient in nodejs)
On 02/06/2017 08:56 AM, fwang2...@gmail.com wrote:
For compared with nodejs:
if I remove all the serverDone case, only left the t
each go routine only handle less than 10 events concurrently, why you said
it's 100?
I found if serverDone is not globally defined, the result is better, but
still not as expected.
在 2017年2月6日星期一 UTC+8上午3:00:15，fwan...@gmail.com写道：
>
> I make a test to see the performance of select, and found t
