Closed StevenLeRoux closed 5 years ago
Hi, thanks for the contribution. Do you have any evidence that disabling GC improves results in some way? I'm actually considering removing the --gc flag from the server entirely, and removing the current code that disables GC on the client.
Also, I believe that there's very little put on the heap while the test is running anyway, so I expect that the effect of GC being either disabled or enabled won't make much of a difference, but I'll change that view if there's evidence otherwise. :)
I agree. Given the heap implicated, disabling the GC shouldn't bring significative gains. I haven't tested in many different contexts, but from what I've seen, there wasn't any difference.
In my case, I want to make use of your library to build a distributed networking monitoring tool. This way, an node can be both a client and server. This makes disabling GC hard since we it implies synchronizing clients and servers instances which in a mesh like topology whould result in too much complexity for a monitoring purpose.
I let you close the PR if you want to clean the GC stuff then ?
I've removed the GC disabling code from the client and server.
This PR adds the ability for the client to disable the GC like the server.
Warning : it breaks the current behaviour. DefaultGCMode is on by default, reusing it makes the client to avoid stopping the GC. Then you have to explicitely pass --gc=off to the client if you want it to stop the GC.
It's broken but it's aligning both client and server with the same behaviour.
If you don't want it to break things, I can add a DefaultClientGCMode to define a different behaviour.