[go-nuts] A lot of garbage from runtime.newselect. Why?

On Fri, Oct 17, 2014 at 9:46 PM, Marko Kevac wrote:
Hi.

Here is minimal example: https://gist.github.com/mkevac/2006f7fa8be38fb1ee00
I have channel that I sent to and receive from. One of the senders\receivers
uses select. And seems that each select creates a little bit of a garbage.

marko@fedora-server:~/goprojects/src/badoo/heaptest $ ./heaptest
2014/10/17 20:59:31 profile: memory profiling enabled,
/tmp/profile883713528/mem.pprof
^C2014/10/17 20:59:40 profile: caught interrupt, stopping profiles
marko@fedora-server:~/goprojects/src/badoo/heaptest $ go tool pprof
--alloc_objects ./heaptest /tmp/profile883713528/mem.pprof
Adjusting heap profiles for 1-in-4096 sampling rate
Welcome to pprof! For help, type 'help'.
(pprof) top
Total: 29161720 objects
22648298 77.7% 77.7% 22648298 77.7% newselect
6513152 22.3% 100.0% 6513152 22.3% main.main
256 0.0% 100.0% 256 0.0% runtime.mallocinit
14 0.0% 100.0% 14 0.0% allocg
0 0.0% 100.0% 270 0.0% _rt0_go
0 0.0% 100.0% 22648298 77.7% main.loop
0 0.0% 100.0% 14 0.0% mcommoninit
(pprof)

If I use channel of integers instead of channel of pointers to integers,
than this garbage is not being created.

Can someone explain what is happening here?

Marko.

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

On Fri, Oct 17, 2014 at 9:53 PM, Dmitry Vyukov wrote:

It creates *allocations*, not garbage.
And, yes, it is misleading.
Select uses explicit freeing of memory rather than relies on GC. So it
does not produce load on GC, but allocations are significantly skewed
towards select.
I've fixed it in Go1.4. Select won't cause allocations anymore.

On Fri, Oct 17, 2014 at 10:06 PM, marko@kevac.org wrote:
Thank you, Dmitry.

Is it the only case when allocation is showed in memory profiler, but does
not produce load for GC?



--
A. Because it breaks the logical sequence of discussion
Q. Why is top posting bad?

On Sat, Oct 18, 2014 at 7:33 PM, Dmitry Vyukov wrote:

There were few other cases, but they are not important (like freeing
env var string during startup).
In Go1.4 I've removed explicit free entirely, so now it's not even
possible. Everything that's allocated produces load on GC.
integers,

On Sat, Oct 18, 2014 at 8:26 PM, marko@kevac.org wrote:
Can you please elaborate why is it better than explicit free? I can't see
why GC load and pauses it makes is better.

--
A. Because it breaks the logical sequence of discussion
Q. Why is top posting bad?

On Saturday, October 18, 2014 12:34:33 PM UTC-4, Dmitry Vyukov wrote:

On Sat, Oct 18, 2014 at 8:26 PM, ma...@kevac.org <javascript:> <
ma...@kevac.org <javascript:>> wrote:
Select descriptors are not allocated on stack, which is even faster
and does not produce GC load. Everything else was not important
performance-wise.


<javascript:>> wrote:
ma...@kevac.org <javascript:>> wrote:
<javascript:>>
it
skewed
<javascript:>> wrote:
pprof

On Sat, Oct 18, 2014 at 8:56 PM, Ugorji Nwoke wrote:
Did you mean to say: select descriptors are *now* allocated on stack???
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.