Feature #901
Client should round-robin sync with core's persistent buffers rather than doing an entire channel.
| Status: | New | Start: | 11/03/2013 | |
| Priority: | Normal | Due date: | ||
| Assigned to: | - | % Done: | 0% |
|
| Category: | - | |||
| Target version: | - | |||
| Complexity: | ||||
| Votes: | 1 (View) |
Description
I like to set my persistent buffers quite high but this raises the cost of client sync during a connect. During this time the client is also very unresponsive.
"Low bandwidth" option is not really good either as that avoids syncing completely.
Instead on fully syncing each channel one-by-one, you should sync all channels by 50 lines, then syncing the next 50 lines (etc) until all channels are completely synced. Perhaps also decrease the priority of the syncing thread, or whatever it is that is hogging all the CPU during this process.
Both of these in conjunction, should massively improve average response times.
Related issues
| related to Smuxi - Feature #546 | Cursor-based frontend/backend communication / dynamic backscroll | New | 11/09/2010 |
History
Updated by Mirco Bauer 4069 days ago
I agree, the long term solution for this issue will be cursor/on demand based syncs. It will by default only load 1.5 - 2 pages per chat per default and only request more if you scroll up, see #546
Updated by Mirco Bauer 4069 days ago
For the record, Smuxi currently uses 4 concurrent syncer threads to compensate expensive network round-trips. The best-case for that will be a single request that fetches all needed state. (a new sync protocol is planned for that)