Describe the bug
I recently had the chance to run nyxx on a bot with a few thousand members, and noticed the main isolate was processing Gateway events much slower than the Shard isolates were receiving them. A quick profile of the library reveals that 100.00% of CPU time was spent in Cache.filterItems (less than 0.005% of time was spent elsewhere, so it was rounded up):
This isn't acceptable. We need to rework how caching is handled, as it was always a patched-together feature since the rewrite anyway.
To Reproduce
Run a bot which receives many events that update its cache. In my case, I was running client.gateway.listGuildMembers with no filters for a few guilds with other 5000 members in parallel.
Expected behavior
The cache should be much less demanding in terms of CPU usage.
Desktop (please complete the following information):
OS: Linux
Dart version: 3.4.0 (dev)
Nyxx version: 6.2.1
Additional context
Note that this will not cause any bots to go offline, as the shard runners are responsible for keeping the connection alive since 6.0.0. It might however cause the bot to become unresponsive, as the main isolate running any user code is bogged down by cache updates. This also causes the CliIntegration plugin to become useless as it takes a long time for it to catch up and close the client.
This also can't be fixed by setting a lower max cache size.
This issue would also become worse over time as the overall cache size increases.
Describe the bug I recently had the chance to run nyxx on a bot with a few thousand members, and noticed the main isolate was processing Gateway events much slower than the Shard isolates were receiving them. A quick profile of the library reveals that 100.00% of CPU time was spent in
Cache.filterItems(less than 0.005% of time was spent elsewhere, so it was rounded up):This isn't acceptable. We need to rework how caching is handled, as it was always a patched-together feature since the rewrite anyway.
To Reproduce Run a bot which receives many events that update its cache. In my case, I was running
client.gateway.listGuildMemberswith no filters for a few guilds with other 5000 members in parallel.Expected behavior The cache should be much less demanding in terms of CPU usage.
Desktop (please complete the following information):
Additional context Note that this will not cause any bots to go offline, as the shard runners are responsible for keeping the connection alive since 6.0.0. It might however cause the bot to become unresponsive, as the main isolate running any user code is bogged down by cache updates. This also causes the CliIntegration plugin to become useless as it takes a long time for it to catch up and close the client.
This also can't be fixed by setting a lower max cache size.
This issue would also become worse over time as the overall cache size increases.