https://bugs.kde.org/show_bug.cgi?id=481389
Simon Redman <si...@ergotech.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INTENTIONAL
Status|REPORTED |RESOLVED
--- Comment #1 from Simon Redman <si...@ergotech.com> ---
(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)
--
You are receiving this mail because:
You are watching all bug changes.
