From 03cd6ff433d42c1e1b91800cdc93dd6aa108e99d Mon Sep 17 00:00:00 2001 From: Rapptz Date: Mon, 5 Jul 2021 21:41:32 -0400 Subject: [PATCH] Remove calls to gc.collect in ConnectionState For some bots this was actually a performance bottleneck, might as well remove it if it causes bad performance --- discord/state.py | 18 ------------------ 1 file changed, 18 deletions(-) diff --git a/discord/state.py b/discord/state.py index a04ce80fa..f51c50372 100644 --- a/discord/state.py +++ b/discord/state.py @@ -32,7 +32,6 @@ from typing import Dict, Optional import weakref import warnings import inspect -import gc import os @@ -215,11 +214,6 @@ class ConnectionState: self._private_channels_by_user = {} self._messages = self.max_messages and deque(maxlen=self.max_messages) - # In cases of large deallocations the GC should be called explicitly - # To free the memory more immediately, especially true when it comes - # to reconnect loops which cause mass allocations and deallocations. - gc.collect() - def process_chunk_requests(self, guild_id, nonce, members, complete): removed = [] for key, request in self._chunk_requests.items(): @@ -332,10 +326,6 @@ class ConnectionState: del guild - # Much like clear(), if we have a massive deallocation - # then it's better to explicitly call the GC - gc.collect() - @property def emojis(self): return list(self._emojis.values()) @@ -1396,14 +1386,6 @@ class AutoShardedConnectionState(ConnectionState): self.dispatch('connect') self.dispatch('shard_connect', data['__shard_id__']) - # Much like clear(), if we have a massive deallocation - # then it's better to explicitly call the GC - # Note that in the original ready parsing code this was done - # implicitly via clear() but in the auto sharded client clearing - # the cache would have the consequence of clearing data on other - # shards as well. - gc.collect() - if self._ready_task is None: self._ready_task = asyncio.create_task(self._delay_ready())