When we don't request offline members, members that are going from
offline to online in the server will become available via the
PRESENCE_UPDATE event. This should be transparent to the user since
technically the member exists in the server and thus on_member_update
is used instead of on_member_join.
Replaced server member lists, channel lists, and private channel lists
with dicts. This allows O(1) lookups and removes (previously it would be
an O(N) operation to lookup or remove). I did pretty extensive testing
and benchmarking to compare the performance of using lists vs using
dicts. Iterating through lists to find an item is only faster in the
average case for extremely small lists (less than 3 items). For 100
items, using a dict is about 10 times faster on average (and about 100
times faster for 1000 items). The overhead in dicts is in memory usage
and initial creation time. Creating and populating a dict is about 2 to
3 times slower than creating and appending items to a list. However this
cost is still tiny. For 1000 items this equates to about a 70
microsecond difference (on an i7 CPU) for populating the entire dict.
The memory overhead for a dict (compared to a list) is about 25-60 KB
per 1000 items (can vary depending on dict resizing).
Originally I wanted to use OrderedDicts to presereve order, but in my
testing OrderedDicts have about 6x the memory overhead compared to
normal dicts.
Previously we created a copy of the object and did some strange
iteration over the data and set the attributes that we thought
were valid. This worked back then in v0.1.0 of the library when
it was written, but it no longer works nowadays when we want to
be as future proof as possible.
This should reduce the amount of checks for None if someone doesn't
want a websocket connection. The connection state is instead cleared
rather than reconstructed.
A lot of the expensive getters were transformed into cached properties
instead. A lot of things that were properties were transformed into
properties as well.
It probably isn't good to rely on an item that was added to a list to
still be the last item, especially if we could have other async
coroutines modify the list. This may not be an actual issue, but having
the function explicitly return the object that it just added to the list
should guarantee that we don't accidentally pull the wrong item from the
end of the list later.
Rapptz
Khazhismel
Steven Berler