diff --git a/main.go b/main.go
index 1985a05a3..099e50a41 100644
--- a/main.go
+++ b/main.go
@@ -26,7 +26,6 @@ import (
 	"os"
 	"path"
 	"runtime"
-	"runtime/debug"
 	"time"
 
 	"github.com/Azure/azure-pipeline-go/pipeline"
@@ -78,7 +77,6 @@ func main() {
 	}
 
 	configureGoMaxProcs()
-	configureGC()
 
 	// Perform os specific initialization
 	maxFileAndSocketHandles, err := ProcessOSSpecificInitialization()
@@ -90,16 +88,6 @@ func main() {
 	glcm.Exit(nil, common.EExitCode.Success())
 }
 
-// Golang's default behaviour is to GC when new objects = (100% of) total of objects surviving previous GC.
-// But our "survivors" add up to many GB, so its hard for users to be confident that we don't have
-// a memory leak (since with that default setting new GCs are very rare in our case). So configure them to be more frequent.
-func configureGC() {
-	go func() {
-		time.Sleep(20 * time.Second) // wait a little, so that our initial pool of buffers can get allocated without heaps of (unnecessary) GC activity
-		debug.SetGCPercent(20)       // activate more aggressive/frequent GC than the default
-	}()
-}
-
 // Ensure we always have more than 1 OS thread running goroutines, since there are issues with having just 1.
 // (E.g. version check doesn't happen at login time, if have only one go proc. Not sure why that happens if have only one
 // proc. Is presumably due to the high CPU usage we see on login if only 1 CPU, even tho can't see any busy-wait in that code)