Caching improvements

[appellation]

This issue is intended to be a discussion/feature request about the possibilities of caching improvements. There are two main areas that I would like to discuss:

Toggleable cache types

The main goal with being able to enable and disable particular caches would be to save memory on storing stuff that the bot would not need to access. For instance, bots could disable emoji caching if they simply didn't use emojis.

External caching

Being able to use an external cache like Redis would be a benefit for any bot that needs other software to have access to its data. I'm particularly thinking of web interfaces in this case, but the applications are wider. This has the added benefit of allowing the cache to be decoupled from the bot and moved where needed.

This would make cache access an asynchronous operation which would have a significant impact on a large portion of the library.

[amishshah]

I mean you could just disable the emoji events

[iCrawl]

I like the idea of caching externally or even disable caching completely so I could have a middleman that handles my caches and events, and the bot logic abstracted.

[bdistin]

To keep this issue up to date, it was brought up through discussion that custom emojies come in on the guild events, and disabling the emoji events will not prevent the emoji cache from creation/fill.

[yonilerner]

The ability to configure which types of things not to cache would be great. For example, it would be really nice to disable caching of users, in instances where thousands of users & their related data gets cached and consumes lots of memory.

[JMTK]

Are there any short term solutions for this? I was just asking around in the D.js server but it doesn't seem like it. Over a long time I end up with an exceptionally large user map across 4 shards ([42595,34314,30945,61286] users on each respective shard). I'd like to offload this somehow if possible.

I am currently on the latest Master (as of September). I am not using fetchAllMembers.

Doing some heapdump comparsions, the largest objects are the guildmembers/client user maps. It's growing quite a lot and usually run out of the 4 GB memory on the server that I'm hosting this on. Simply restarting the process fixes the issue until about a week later when it's out again.

(From the top of a heapdump comparison)

I do use presenceUpdate feature for some servers so I feel like I'm wanting to have my cake and eat it too but if there's anything I can do to limit it, I'd like to help with this.

I've done everything I can to make sure this isn't a memory leak with bad function closures or something I could've caused, but I think just the raw number of users is the problem for me right now.

[zakius]

@yonilerner in my case caching of users is especially bad since I'm trying to parse data that is passed partially as username, which is cached

[ooglyboogly]

Looking forward to disabling caching certain objects in v12. Mainly user caches. Or at least the ability to flush them every so often.