Add maxsize to internal member and user cache

[circuitsacul]

Summary

Right now there's an easy way to determine the max size of the message cache. I think it would be very useful, at least for large bots, to have a way to also set the max size for the member cache.

Why is this needed?

Some large bots may have hundreds of thousands or millions of members total (and around that in users). This means that the bot either needs to have a VPS with a lot of RAM, override the user/member cache (as well as some cache methods), or just have a loop that clears the member/user cache on a certain interval. None of the options are ideal.

Ideal implementation

Ideal

I imagine doing this for the user cache should be very straightforward (just do whatever is done for messages). As for the members, since members seem to be stored on the Guild objects (and not in their own cache), you could do something like this:

• Make a new list type that
  • Accepts references to other lists
  • Has a length that is the sum of the length of the other lists
  • Has a __getitem__ which determines which list reference to pull from.
• Store a new variable on cache called _member_ref
• Every time a Guild is added to the cache, also add the Guild's member list/cache to this new variable
• Ever time a Guild is removed from the cache, remove the list reference from this variable
• When a Member object is added to a Guild, also trigger some method on this new variable which determines if it is too large. I'm not sure how poping from this "cache" would work, though.

Alternatives

I can think of two alternative implementations. (1), store all members in the same way uses are stored, and find some way to have Guid just reference a subset of that cache (idk if this would even work) or (2) have a per-guild member cache size. This isn't ideal but is better than letting the member cache get as large as the total number of members a bot has.

I'll probably just disable the member cache for myself, since I don't ever query large groups of members by guild, but I figured this is still something worth mentioning.

Checklist

• I have searched the issue tracker and have made sure it's not a duplicate. If it is a follow up of another issue, I have specified it.

[FasterSpeeding]

The standard user cache is referential only and mostly serves for deduplication; a max size wouldn't make sense for it as these user entries will still be in the cache regardless on other cached objects.

(I'll comment on the member cache bit later though, it's a bit more to unwind)

[circuitsacul]

The standard user cache is referential only and mostly serves for deduplication; a max size wouldn't make sense for it as these user entries will still be in the cache regardless on other cached objects.

Ok, that makes sense. That also answers my question about why "delete_user" and "clear_user" methods don't exist.

(I'll comment on the member cache bit later though, it's a bit more to unwind)

All right.

[circuitsacul]

(I'll comment on the member cache bit later though, it's a bit more to unwind)

Any update on this?

[FasterSpeeding]

To be honest, you likely shouldn't be using the member cache if this is of concern to you since it can't be designed to be optimal for that use case. Large bots should really be avoiding relying on the library's built in member cache for numerous reasons and would be better suited to a custom solution that can keep members cached between restarts of the bot logic and has whatever features suit their specific needs (e.g. a lru cache strategy) and slash commands should in theory be alleviating a decent amount of the need for this as you get the member objects of the user who's executing the command + whoever they targeted + permissions.

Fwiw #878 (comment) is going to be implemented as part of the thread cache and this may be a more universally helpful way to lower the member cache without having to make rest calls for every request.