Sending a message sometimes becomes slow on chats with many messages / sometimes draft is not removed

[hpk42]

Those of you who are with me in some chat groups will have seen that i sometimes sent "double messages".
This happens because when i hit "CTRL-return" or click the send button in a group chat with many messages, it takes 3-10 seconds until the message is sent, and then i click a second time because i wrongly think i hadn't clicked it. Sometimes, the draft-message doesn't even go away.
In chats with only few messages, i do not experience the problem. It's smooth/swift there.
Sometimes it seems to be even fast in chats with many messages.

It's all the same database, so my best guess it that something in the sending-logic (changing a draft message to a sent one) might iterate over all messages in a chat. But whatever the guess, it would be great if someone more knowledgable of the code can take a look into what happens when the send-button is clicked.

[Simon-Laux]

It's all the same database, so my best guess it that something in the sending-logic (changing a draft message to a sent one) might iterate over all messages in a chat.

if so its core being slow with sending as the code waits for core.

Anyways this code area is in high need of rewriting. see https://github.com/deltachat/deltachat-desktop/milestone/9

[hpk42]

On Wed, Mar 27, 2024 at 05:53 -0700, Simon Laux wrote: > It's all the same database, so my best guess it that something in the sending-logic (changing a draft message to a sent one) might iterate over all messages in a chat. if so its core being slow with sending as the code waits for core.

I find this unlikely as on Android i never have this problem. If i had in on both i'd file it directly on core.

[Simon-Laux]

so on android you never have delays while sending?
I have a hard time imagining that desktop ui code has delays that depend on message count in the chat as unless you scrolled to load messages only the most recent 20 or so messages are even loaded and displayed in the ui, but even then it should have nothing to do with sending.

[hpk42]

On Wed, Mar 27, 2024 at 10:04 -0700, Simon Laux wrote: so on android you never have delays while sending?

no, i don't have delays there.

I have a hard time imagining that desktop ui code has delays that depend on message count in the chat as unless you scrolled to load messages only the most recent 20 or so messages are even loaded and displayed in the ui

maybe it is something else and not the number of messages in a chat because sometimes it's also fast in large chats and the app is sometimes slow at other occassions eg when clicking around in the chatlist which is usually fast but sometimes takes 5 seconds as if something would be blocking. Could it be that core is generating events, causing re-rendering and then reacting to user-input is delayed?

[hpk42]

currently things are super-fast. I'll close this issue and try to come back with a clearer way to reproduce as apparently no one else seems to experience the issue.

[Simon-Laux]

you already reported the delays before in #3586

#3739 might fix the double sending aspect by fixing the lock

To really make this nice we need to rewrite the composer, but we don't have time for that soon (maybe may if we are lucky with the other things). So let's test #3739 to at-least fix the double sending.