perf: improve jumpToMessage speed
#4584
Conversation
WofWca
commented
Jan 29, 2025
WofWca
commented
- refactor: remove outdated comment
- refactor: simplify jumpToMessage
- refactor: simplify jumpToMessage again
- perf: improve jumpToMessage speed
WofWca
force-pushed
the
wofwca/perf-jumpToMessage-2
branch
from
8bf2614 to
eb92265
Compare
By removing an unnecessary `await rpc.getMessage()`.
WofWca
force-pushed
the
wofwca/perf-jumpToMessage-2
branch
from
eb92265 to
24f4f32
Compare
| // so we know the chatId in advance. | ||
| // However, let's keep the code that supports arbitrary chatId, | ||
| // which can be "enabled" by setting `chatIdPreset = undefined`. | ||
| const chatIdPreset: number | undefined = this.chatId |
There was a problem hiding this comment.
You mean that there is (should?) be no use case at the moment, where this.chatId is not set and/or is different from the jumpToMessage.chatId ?
Since later we log an error if isMessageInCurrentChat is false.
If so, you leave the code since it might be useful if we extend the usage later or just as a fallback if this function is called "wrongly" for a message that belongs not to current chat?
There was a problem hiding this comment.
You mean that there is (should?) be no use case at the moment, where this.chatId is not set and/or is different from the jumpToMessage.chatId ?
Unless there is a bug that I missed, currently we never call this jumpToMessage with a msgId that belongs to a chat whose ID is not this.chatId.
Since later we log an error if isMessageInCurrentChat is false.
Yes, that would be unexpected.
If so, you leave the code since it might be useful if we extend the usage later or just as a fallback if this function is called "wrongly" for a message that belongs not to current chat?
I guess it's for the former case mostly.
But maybe also for the latter, because I am not sure if we'd want to just throw an error instead. In this regard I kept things as they were before me.
