Discord.js: 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.

[bdistin]

Beyond just turning off certain caches, it would be more ideal to give some sort of way for users to control what is cached from the very beginning, instead of caching everything and requiring caches to be swept.

This could be done with:

• basic limits (like the message cache)
• filter functions for users to determine what should be cached
• maybe lru (like the channel cache, for which you cannot actually even use currently)

[appellation]

This has been determined to be unreasonable for a library like discord.js that relies heavily on internal state in order to function.

[Headline]

@appellation this appears to still be a significant problem - is there any possible way we can get some cache restrictions? This was deemed "unreasonable", but this issue makes this library unreasonable for any large bots.

I genuinely love this project, been following it for a few years now, but we really need some sort of solution to the aforementioned problem.

[appellation]

@Headline I wouldn't say that either of these proposed solutions are off the table for the discord.js-next rewrite, but I am also no longer involved in the community to a degree where I could confirm a bias towards one, the other, or potentially a new solution.

I absolutely agree with your concerns, but the bottom line is still that this concept is unreasonable for the current implementation of discord.js.