fetch() vs cache.get() war

[forest cradle]

Before you all get a timeout

👋

[crisp egret]

Good idea

[forest cradle]

@vagrant viper

Channels and guilds are always cached.

Presence only cached when intent is enabled + user has any presence

member only cached when fetched once, retrieve through a member related event, or the first couple hundred members on guild create event(which includes ready event)

emojis are always cached
Voice states are always cached
Users are only cached when the member is cached, or the user dmed the bot

[mild tundra]

Why fetch when they’re cached

[vagrant viper]

What

[mild tundra]

If you have an actual pro which makes logical sense then please share

[crisp egret]

Cause if they're not cached, you get an extra check on if that user exists?

or channel

[mild tundra]

They are cached

[crisp egret]

You're assuming that the cache is never wrong then

[mild tundra]

Do you mess with sweepers or you don’t have the guilds intent?

[forest cradle]

I think the simple reason I use fetch is for 2 reasons:
1)
Despite what you say about it "already being cached", it gives me a sense of certainty that in a 1 in a million edge-case, I'll still have a result at the end.

I am fully comfortable with Promises, and have no problem dealing with them, and anyone scared of Promises needs to get a grip

[mild tundra]

It isn’t if you have the Guilds intent

[forest cradle]

To clarify point 1, it might be irrational, but it's how I feel

[vagrant viper]

If a user exists (in general)
You cant outreach an fetch.

If the user id available from the bot (sharing dms/guild€) then after the first fetch it will get cached.

[crisp egret]

I get that .fetch() would use up rate-limits. But for smaller apps isn't that okay?

[mild tundra]

I understand, you’re much more proficient in js however

[vagrant viper]

For smaller apps its fine

[forest cradle]

It doesn't use any rate limits if they're cached, so it's not actually an issue.

fetch when cached = cache.get + promise

[mild tundra]

But it adds a fetch part to it which you basically don’t need

[mild tundra]

cache.get ≠ promise

You’re just removing that element

[vagrant viper]

A cache is a store.

With the cache u store what the api returned to u somewhen in the past.

If u can get it out of the store, get it out of there. Why do a fetch if its in there...

Thats what they are saying.

[mild tundra]

It would be marginally faster

[vagrant viper]

Someone wanna contribute to my advanced logger with over 300 events

[mild tundra]

I don’t see any logical reason to fetch over getting it from the cache, only personal preference

[mild tundra]

Send it my way 🙏😏

[vagrant viper]

By creating discord issues

[crisp egret]

But if speed isn't the problem, but data-consistency?

[mild tundra]

Channels are

ALWAYS

cached

Unless you have sweepers, or you don’t have the guilds intent

[mild tundra]

Sweepers pointing to the channel managers

[vagrant viper]

Channels are always in the cache.
If ur bot has somehow access to them (beeing in the guild of the channel)

Even the channels the bot cant see aka doesnt have perms for view channel

[nocturne swan]

It's just a marginal data consistency

[vagrant viper]

if you look in the RAW EVENT
Youll see that once the bot gets ready it retrieves for all guilds data, which includes for every guild presences, parts of the members, channels, emojis and voicestates as well as guild data like guild owner id guild name etc.

[nocturne swan]

If you have a lot of time,
Then, take your time, fetch your stuff,
If you want to be quicker, use cache
That's all

[forest cradle]

Here we go, the inner-working of GuildMemberManager:

  async _fetchSingle({ user, cache, force = false }) {
    if (!force) {
      const existing = this.cache.get(user);
      if (existing && !existing.partial) return existing;
    }

    const data = await this.client.rest.get(Routes.guildMember(this.guild.id, user));
    return this._add(data, cache);
  }

Literally, if they exist in the cache, it returns them, so a fetch for a cached entry, is a cache.get + promise, like I said @mild tundra

https://github.com/discordjs/discord.js/blob/4e0e1250399aa12c340ac92a86ec2c05704fe2bb/packages/discord.js/src/managers/GuildMemberManager.js#L215

[mild tundra]

So in turn keeping the promise part of that function, correct?

Whereas cache.get() is not a promise

[vagrant viper]

handling promises shouldnt be a problem since 2015

[forest cradle]

and what's wrong with a promise?

[mild tundra]

Adds time probably

Idk if it doesn’t then go for it

But imo if it’s there use it

[forest cradle]

Yea, this is true, but do you need to worry about that?

[vagrant viper]

Not really

[forest cradle]

You only need to worry for BIG bots

[vagrant viper]

Just couple ns

[crisp egret]

If those .xxx ms matters to you, then you're big

[vagrant viper]

For me they do

[mild tundra]

I don’t particularly no, but if it’s there I suggest that you should recommend to use it rather then fetching

[vagrant viper]

my bot responds in 6ms for any discord action, my ws ping is 5-8ms on avg

So if i need to wait 10ms until something happens it feels mega slow

[nocturne swan]

Not really

[vagrant viper]

But if i need to wait 0.001ms its super faster

[mild tundra]

I just feel if it’s there and reliable use it

The channel cache is super reliable unless you mess with anything

[crisp egret]

But if you're working around a database, so everything is already async - it doesn't really break anything adding another await

[forest cradle]

About 1.5x longer to take

[mild tundra]

0.004ms

[vagrant viper]

My db answers within 0.4 and 0.8ms

And i cache it which makes it answer in couple ns again

[crisp egret]

but still async? @vagrant viper

[vagrant viper]

For get requests

Yes

a promise doesnt mean slow

It just means slower than no promise

Cause nodejs needs to create and close the promise

[crisp egret]

100% agree

[mild tundra]

I don’t see a logical reason to do it unless it’s not cached 🤷🏻‍♀️

[vagrant viper]

Something like navijs is faster in promises than nodejs

[forest cradle]

So 100th of a second, or 7,000ths of a second
So yea, so small

[vagrant viper]

Yea i do the same, but for simplicity its jot worth it

[mild tundra]

It’s very small yh but I just find it unnecessary

[forest cradle]

"irrational feeling" - you're utterly right

[crisp egret]

But we're still arguing .fetch vs .cache.get

[mild tundra]

Yes

We know

[crisp egret]

No need to hate on people using it than, or guide them into not using it.

[mild tundra]

Not hating anyone for using it

[forest cradle]

The only harm in using fetch, is time

[mild tundra]

Never did i state that it is better, I’m saying that I don’t think people in this server should recommend it due to most people having problems with promises

[nocturne swan]

What's the problem with promises though?

[crisp egret]

If you're new to Javascript, you gotta learn about async

before using them

[nocturne swan]

Oh yea ☠️

[mild tundra]

50% of the people in #djs-help-v14 #archive-djs-help-v13 don’t know anything about them?

[nocturne swan]

Hmm ☠️

[mild tundra]

50% is VERY generous

[crisp egret]

80%

[mild tundra]

So just tell them to use cache.get considering its reliable for channels

And roles

[forest cradle]

If you have a problem with promises, you should leave the Server, simple as that. (not you specfically)

[nocturne swan]

Damn ☠️

[mild tundra]

🤣, I mean we are here to teach as well, in some ways

[forest cradle]

DJS is littered with promises, you should not be here until you understand their basics

ala #rules 2

[crisp egret]

Mostly @mild tundra been pointing out how shit I am to remembering to do stuff async. That's a huge help

(really 😅 )

[mild tundra]

I don’t think promises are basic basic thoigh

[crisp egret]

I find async await better than the .then notation

[forest cradle]

If you want to use DJS, they are

If you were to use no promises, then you can't use DJS

[mild tundra]

I’m talking javascript

[forest cradle]

Not knowing Promises for DJS, but knowing JS, is like knowing how a Car works, but not how to Drive

[mild tundra]

That’s not what I’m saying, I said I don’t feel promises are something very very basic within the js scope

[vagrant viper]

new Map().get()
Faster than

const map= new Map()
return new Promise(r =>{
r(map.get())})

Thats what they say

[forest cradle]

I did that earlier, 1.5x slower

[mild tundra]

So 5 of them in one scope would be 7.5 times slower, no?

[crisp egret]

And nobody said .fetch() was faster. It was about making sure you have new information before doing an action.

[forest cradle]

Indeed

[forest cradle]

No...it's individual

Each request would be 1.5x slower, so the 5 promises would take 1.5x the time as 5 gets

[mild tundra]

Yh 7.5x slower because there’s 5 of them

[forest cradle]

No, that's not how math works

[mild tundra]

If each 5 await’s take 1.5x longer then they’ll stack

[forest cradle]

1 x 5 = 5
1.5 = 5 = 7.5

5 / 7.5 = 0.6

[forest cradle]

each takes 1.5 longer, so the total is 1.5x slower still

[crisp egret]

Specific example here @mild tundra - I'm checking if a channel exisits, and it's specific permissionOverwrites.

If it returns a cache miss ( for any reason, I've had it happen in v13, Don't know if it discord was unstable - or it was a cache problem. I had a death loop of creating channels.
(yes, bad code that allows that) But I'm just saying - a cache miss could be a realy bad thing for some people.

[mild tundra]

It won’t be missed lmao

I think we’ve established things here anyway

[nocturne swan]

Channels are always cached

[forest cradle]

If we have 1x, and 2x, the 2x isn't 2+2+2+2+2 = 10x slower...it is 2x slower

[mild tundra]

I don’t think you understand me but as I said it don’t matter anymore as we have established things here

[forest cradle]

I don't think you understand

[nocturne swan]

He was talking about the total time

[forest cradle]

Each being 1.5x slower, doesn't make the whole thing 7.5x slower

[mild tundra]

[forest cradle]

The total time isn't 7.5x slower though

It's still 1.5x

[mild tundra]

[forest cradle]

If you do 1 request, and 5 requests, the 5 take 5x longer

But doing 5 that take 1s, and 5 that take 2s, doesn't make the latter 10x slower

[mild tundra]

Ok

[forest cradle]

they are 2x slower

[nocturne swan]

I know, he probably wanted to say 7.5 and not 7.5x

[mild tundra]

[crisp egret]

[nocturne swan]

[forest cradle]

I will force feed you all an English and Math book 🤣

[mild tundra]

Not really

[crisp egret]

Let's agree to disagree

[mild tundra]

You just said that if you do one promise action it takes 1.5x longer right

So compare 2 cache.gets to 2 promise actions one after the other they’ll stack

[nocturne swan]

Sometimes you need to feel what another wants to say
Everyone is not a robot ☠️

[forest cradle]

They stack, but it doesn't multiple the total time

Simplify it...

Let's say 1x and 2x

1x: 1, 2

2x: 1, 2, 3, 4

For 2 requests

[mild tundra]

Look we’ll agree to disagree lol, you’ve already insulted my maths skills

[forest cradle]

4 is double 2

Let's go with 5 requests

1x: 1, 2, 3, 4, 5

2x:
A, A, B, B, C, C, D, D, E, E
1, 2, 3, 4, 5, 6, 7, 8, 9, 10
Also 2x as long

They queue, they don't multiple the resulting time

[forest cradle]

Just realised an advantage of fetch, it will throw an error if you try and use it when the bot is not ready or Id is wrong, and you'll just get "cannot x of undefined" or the like with a get.