This uses the nonce field to properly disambiguate queries. There's
also some redesigning going on behind the scenes and minor clean-up.
Originally I planned on working on this more to account for the more
widespread chunking changes planned for gateway v7 but I realized that
this would indiscriminately slow down everyone else who isn't planning
on working with intents for now.
I will work on the larger chunking changes in the future, should time
allow for it.
A proper fix for this would be to just request presence information
as well since the chunk request would probably be more up to date than
the current cache. However this delta requires a little bit more work
and will be done later.
This also changes the default to 1000 instead of 5000 since it can
take some time for small bots to cycle through the default and they
make up the majority of it.
Channels are meant to fallback to Object if the message is out of
order. Somewhere along the commit line this got removed despite the
issue still existing.
This has been a massive pain point for me personally due to the poor
design of the Enum class leading to the common use cases used in the
library being significantly slow. Since this Enum is not public facing
in terms of *creation*, I can only implement the APIs that are used
when *accessing* them.
This Enum is a drop-in replacement to the pre-existing enum.Enum class
except it comes with significant speed-ups. Since this is a lot to go
over, I will let the numbers speak for themselves:
In [4]: %timeit enums.try_enum(enums.Status, 'offline')
263 ns ± 34.3 ns per loop (7 runs, 1000000 loops each)
In [5]: %timeit NeoStatus.try_value('offline')
134 ns ± 0.859 ns per loop (7 runs, 10000000 loops each)
In [6]: %timeit enums.Status.offline
116 ns ± 0.378 ns per loop (7 runs, 10000000 loops each)
In [7]: %timeit NeoStatus.offline
31.6 ns ± 0.327 ns per loop (7 runs, 10000000 loops each)
In [8]: %timeit enums.Status.offline.value
382 ns ± 15.2 ns per loop (7 runs, 1000000 loops each)
In [9]: %timeit NeoStatus.offline.value
65.5 ns ± 0.953 ns per loop (7 runs, 10000000 loops each)
In [10]: %timeit str(enums.Status.offline)
630 ns ± 14.8 ns per loop (7 runs, 1000000 loops each)
In [11]: %timeit str(NeoStatus.offline)
253 ns ± 3.53 ns per loop (7 runs, 1000000 loops each)
In [12]: %timeit enums.Status('offline')
697 ns ± 8.42 ns per loop (7 runs, 1000000 loops each)
In [13]: %timeit NeoStatus('offline')
182 ns ± 1.83 ns per loop (7 runs, 10000000 loops each)
Embed edits are no longer special cased in the dispatch code, which
could lead to on_message_edit being called more often than it used to
be called. I am not sure on the general impact on that being removed.
Fixes#2195
Probably not a significant difference but might as well use it here.
The basic idea is to cache the getattr calls instead of repeatedly
doing it (since they're around 105ns on my machine). The dictionary
lookup is about 41ns on my machine.
The next step in speeding up library code some more should be in
the parser bodies themselves but that's a problem to tackle another
day.
This fix is long coming. For a long time due to the addition of a
global user cache, the on_member_update event would only have the
updated user in the very first dispatch due to a quirk in the reference
only being updated once.
In order to fix this issue two things had to change:
1. There had to be a new event, `on_user_update` to complement
the equivalent member event.
2. Unnecessary copies of User had to be removed to compensate for the
performance hit from the diffing.
While doing these two fixes I also re-evaluated some more unnecessary
copies done during the PRESENCE_UPDATE to add member case while
fetch_offline_members=False is set or due to chunking issues. The
number of copies was brought down from 2 to 1, discounting the original
Member creation. Unsure on the benefits of this one, however.
N.B: this doesn't change the pre-existing behaviour of on_member_update
Change `parse_message_delete_bulk` to not dispatch individual
`message_delete` events, and instead `bulk_message_delete`. Also make
`raw_bulk_message` delete and `raw_message_delete` have message
objects attached.
Fixes#1807
Most assets now return a new class named `Asset`. This allows for the
assets to be consistently saved via a `save` method instead of special
casing for `Attachment`.
`AppInfo` is no longer a namedtuple it is a fully documented dataclass,
as well as having the state attached to it.
Fixes#1997
Rapptz
Anurag
Tarek
apple502j
iomintz
NCPlayz
Lorenzo
Vexs
CraftSpider
Dante Dam