[fighting]

Go seems to be still a bit of a black box in terms of performance/memory profiling.

On one recent project, the go memory profiler was showing about 35MB allocated while top showed memory usage at 500MB to 1GB. In another instance the performance profiler would show microseconds elapsed while the user experienced tens of minutes with no response from the program.

I really think they should consider including a function level profiler instead of just a sampler, as well as provide more insight/control over all the goroutines that are generated.

Just saying golang is better than node.js may not be saying all that much.

[lossolo]

Can you provide more details? Because i didn't encounter such problems. Was this 500 MB in top was RSS ? What you describe should not happen, did you report a bug?

[fighting]

They were more like things the go runtime was doing but which I had no clue or information about, rather than bugs. The top info was indeed rss.

[lossolo]

For me it seems like you probably leaked gorutines/not closed os resources or you encapsulated some data structures in themselves which then can't be garbage collected. It really looks like memory leak caused by app logic. But as i said you should report this if you are certain that is Go bug.

[Torn]

Are you looking at virtual memory / memory-mapped files?

[whateveracct]

Go processes usually have that large amount of in virtual memory, but RSS has always aligned with what Go says in my experience.

[donatj]

I've seen similar things happen when using very large maps in Go, memory being eaten and never released.