FAQ
Hallo Jason,

thanks for the question. I assume you are talking about a server that
services requests coming out of the Internet.

There is a new runtime/scheduler in development right now. It is already
showing very substancial performance improvements in its relatively early
stages, also in terms of scalability. Have a look at the last few posts in
this thread:
https://groups.google.com/forum/?fromgroups=#!topic/golang-nuts/hkd5fjWIGmY

I think the new scheduler is still quite a ways from being finished
however.

So the overall increase in throughput would likely leave more time for GC
in a given time window. It seems to me the biggest issue with the GC now is
that it hast to stop the world.


On Tuesday, September 4, 2012 10:52:45 PM UTC+2, ja...@eggnet.com wrote:

Hello,

It seems one of the requirements of creating a go server that handles a
large number of requests per second is creating little garbage and making
sure that large data structures follow certain rules. This seems to boil
down to eliminating the use of pointers passed between functions or through
channels, using offsets into arrays instead of pointers to elements within
large data structures, and in general not using pointers in large data
structures.

I am assuming that the use of an interface results in heap allocated data
which is then pointed to by the interface value, therefore interfaces can
be lumped into this.

This means you have to remove all pointers/interfaces from function
signatures and channels that are involved in the critical path. This would
be no trivial task particularly considering the standard library makes
heavy use of interfaces, not to mention interfaces being one of the key
abstractions in go.

It seems to me that go tries to be a clean and simple language, but when
you're writing high performance software, you end up having to write go in
a rather obtuse way... and I'm mainly talking about avoiding the passing of
pointers and interfaces between functions or across channels. The data
structure restrictions are pretty inconvenient but, ultimately I think you
don't have to sacrifice too much to follow best practices there.

I'd like to see comments related to the above relative to go1. Also, how
might go change in the future regarding improved GC, escape analysis, and
maybe even addition to the language syntax itself to help with any of these
issues.

Thanks,
-Jason

Search Discussions

Discussion Posts

Previous

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 7 of 7 | next ›
Discussion Overview
groupgolang-nuts @
categoriesgo
postedSep 4, '12 at 10:35p
activeSep 5, '12 at 1:44p
posts7
users5
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase