Re: Disable garbage collection in Go

[Paulo Pinto]

Why do you think disabling the GC would make you win speed?

On Jun 26, 8:15 am, Faissal Graviton <amr.fais...@gmail.com> wrote:
> can i disable the garbage collector in Go in order to gain more speed?
>
> thanks

[Archos]

Because with the GC you could get too many:

+ allocations
+ large allocations
+ pointers
+ roots
+ object writes
+ almost long life objects

[Archos]

On Jun 26, 8:16 am, Archos <raul....@sent.com> wrote:
> Because with the GC you could get too many:
>
> + allocations
> + large allocations
> + pointers
> + roots
> + object writes
> + almost long life objects

http://msdn.microsoft.com/en-us/library/ms973837.aspx

[Jesse McNelis]

On Tue, Jun 26, 2012 at 5:16 PM, Archos <raul...@sent.com> wrote:
> Because with the GC you could get too many:
>
> + allocations
> + large allocations
> + pointers
> + roots
> + object writes
> + almost long life objects
>

Mozilla will tell you that you still get these problems on large
projects even without a GC.

--
=====================
http://jessta.id.au

[Archos]

On Jun 26, 8:32 am, Jesse McNelis <jes...@jessta.id.au> wrote:

> On Tue, Jun 26, 2012 at 5:16 PM, Archos <raul....@sent.com> wrote:
> > Because with the GC you could get too many:
>
> > + allocations
> > + large allocations
> > + pointers
> > + roots
> > + object writes
> > + almost long life objects
>
> Mozilla will tell you that you still get these problems on large
> projects even without a GC.

I don't think that Faiisal neither another people who wants to work
with GC disabled, go to build a project so long like a browser.

[DisposaBoy]

I'd you actually measure it you'll more than like find that the performance of the GC in in the gc runtime isn't as bad as you'd assume.

[Ian Lance Taylor]

Faissal Graviton <amr.f...@gmail.com> writes:

> can i disable the garbage collector in Go in order to gain more speed?

Set the environment variable GOGC to "off".

GOGC=off go run program

Ian

[Faissal Graviton]

I don't think that Go is designed to be usable with the GC disabled. I mean disabling the GC can help me tackle some real time constraints but Go isn't the kind of language to use in real time computing.

[dustin norlander]

This is interesting.. Though, afaik there is no way to explicitly free
allocated objects (thus turning off gc would be of limited usefulness).
Am I wrong?

--
var Dustin_Norlander = { Trendrr : 'Chief Technology Officer',
contact: ['dus...@trendrr.com', '@dustismo', 'x130'],
github: ['github.com/dustismo', 'github.com/trendrr']
}

[Ian Lance Taylor]

dustin norlander <dus...@trendrr.com> writes:

> On 06/26/2012 06:39 AM, Ian Lance Taylor wrote:
>> Faissal Graviton <amr.f...@gmail.com> writes:
>>
>>> can i disable the garbage collector in Go in order to gain more speed?
>> Set the environment variable GOGC to "off".
>>
>> GOGC=off go run program
>>
>> Ian
>
> This is interesting.. Though, afaik there is no way to explicitly
> free allocated objects (thus turning off gc would be of limited
> usefulness). Am I wrong?

You are correct.

Even if there were an explicit free function, Go programs routinely
allocate memory implicitly. Tracking that memory would be quite
difficult, and any attempt to free it would require the use of the
unsafe package.

Disabling the garbage collector is only of interest for testing
purposes, or possibly for programs that only run for a short time.

Ian

[Maxim Khitrov]

What is the behavior of runtime.GC() if the program is started with GOGC=off?

I also think there could be some utility in having the
runtime.SuspendGC() and ResumeGC() functions that Erik proposed, if
the goal is to manually call runtime.GC() at appropriate points in the
execution.

- Max

[andrey mirtchovski]

> What is the behavior of runtime.GC() if the program is started with GOGC=off?

it returns before any GC is attempted. src/pkg/runtime/mgc0.c:881

[⚛]

On Tuesday, June 26, 2012 8:15:08 AM UTC+2, Faissal Graviton wrote:

can i disable the garbage collector in Go in order to gain more speed?

 

In case of your own code, it may be possible to implement a custom allocator in Go. Then, the universal method to make GC finish sooner is to avoid pointers - use integers instead. An integer can act as a pointer as long as the programmer knows that the integer points to something (such as: it can be an index into an array of objects). This results in writing more Go code and requires you to write some memory management code in Go and may slightly lower the performance of the application, but if you want faster GC this method does work. In almost *any* Go program, it is possible to bring the GC pause time under 1 millisecond - the only question is how much programming work it costs.