You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Describe the bug
![screenshot](https://private-user-images.githubusercontent.com/54505189/319334880-dd87e0a3-d64c-460b-9282-94b55ca3dab8.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjE3NjE0MjcsIm5iZiI6MTcyMTc2MTEyNywicGF0aCI6Ii81NDUwNTE4OS8zMTkzMzQ4ODAtZGQ4N2UwYTMtZDY0Yy00NjBiLTkyODItOTRiNTVjYTNkYWI4LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA3MjMlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwNzIzVDE4NTg0N1omWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTk5Y2NiYTRkZjJmNmI4NjY5OTMzYTBiNmI3NmZmY2ZmMWZkNzE3ZWEzZTdhZmRhMTkyZWRkMTIwNjg1NjZhYmMmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.Y4WB--RfnmB5oOOoi-oVG9AzG0Dtrm9d-ctO6TEV6Zo)
![screenshot](https://private-user-images.githubusercontent.com/54505189/319335294-794e6de4-a176-4393-8477-1f63d762449a.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjE3NjE0MjcsIm5iZiI6MTcyMTc2MTEyNywicGF0aCI6Ii81NDUwNTE4OS8zMTkzMzUyOTQtNzk0ZTZkZTQtYTE3Ni00MzkzLTg0NzctMWY2M2Q3NjI0NDlhLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA3MjMlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwNzIzVDE4NTg0N1omWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTcyNjBjZDhhYzM1YzE0OTA4MGEwZmQwNWIyZmM2OGQzNTIxNTg2M2RhMDMzMDg4OWYwNjA1MGM0ODNkZTQ1M2QmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.meEpN4WXtkGdLpz-8irhw4X3BzjO_GKRzi58_WuaIc4)
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):
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.
The text was updated successfully, but these errors were encountered: