(In reply to Robert Walker from comment #0)
> PROPOSAL:
> When I began looking at this I thought the original fix to this issue might
> be caching messages to a local DB and revising that implementation, but I
> have had another idea I want to share with the developer. I think may take
> significantly less time and testing. I believe this is observed behavior
> that is behind many bug reports on this site, and off-site threads I have
> observed exploring KDEConnect (stack, reddit, etc.).
> 
> I have deleted over 130k of my messages to reduce the SMS load to a more
> reasonable "1 year of history" and have roughly 35k messages. With this
> done, the app is snappy and works great, as expected. 
> 
> I believe allowing a configuration setting for the plugin (or perhaps it
> best lives in the KDEConnect app to reduce SMS parsing?) to only load the
> last "X" messages or since "Y" date would fix many performance issues and
> give 99% of users the experience they are looking for - the ability to
> respond to relatively recent messages with snappy performance and reliable
> transit, without adding additional logic to caching messages or establishing
> new databases/data integrity. 
> 
> I believe most users want to respond to current messages, or messages from
> recent memory, when using this program effectively. Adding these settings
> would be a "low cost" way to address performance issues for large SIM
> databases without asking users to delete messages from their record source.
> Thanks for your consideration.

Thanks for sharing this suggestion and the finding. I had not considered deleting messages, it's very interesting this is a significant speedup.

At least in the current master build of KDE Connect, the behavior you have described is how it is implemented. The desktop requests the list of conversations, and the phone sends back the first message in each conversation, sending the newest first. Presumably, users most-used contacts will float to the top of this ordering.

When a user selects a conversation, the first messages (I think always 10, but maybe I was clever and made it dynamic) are fetched. As you scroll back in history, more messages are fetched, doubling each time first 10, then first 20, then first 40 ... Yes, wasted effort, but extremely easy to implement correctly, and performs adequately.

This will get more fluid in the next Android release, because a few days ago a change went in to put all the SMS fetching into a separate thread, so the conversation list can be fetched, at the same time as fetching the history, at the same time as sending a message.

I suspect the speedup you're experiencing is because all Android devices (that I know of) use SQLite as the backend for storing messages, and that presumably gets slower as the tables (indices, etc.) get larger. That's just my guess, I'm far from a SQLite expert.

(In reply to Robert Walker from comment #0)
> Have observed messages "lost" on send
This in particular, I assume is due to either the message being sent while the device was actually disconnected (and the UI didn't know), or when other stuff was blocking the main worker thread in KDE Connect Android, causing the packet to be dropped (see note above about putting it all into threads)

Thanks for the consideration and info - great to know different SMS functions will have their own threads.

I'll continue to monitor and try to contribute how I can. I think this is a great effort and something that I find very valuable; if there are other ways I can contribute please don't hesitate to ping me (testing, documentation, etc.). I'm new to the KDE project but have a pretty significant C# & SQL background and hope to get involved soon. Thanks for the effort!