Feature #546
Cursor-based frontend/backend communication / dynamic backscroll
| Status: | New | Start: | 11/09/2010 | |
| Priority: | Normal | Due date: | ||
| Assigned to: |  Mirco Bauer |
% Done: | 0% |
|
| Category: | Frontend GNOME | |||
| Target version: | - | |||
| Complexity: | High |
|||
| Votes: | 4 (View) |
Description
It seems that, currently, the Smuxi frontend maintains a copy of a lot of the backend's IRC state, and needs to synchronise these on server connect. This results in connecting to the backend taking a significant period of time (for me, around a minute) and consuming a significant amount of memory (again for me, Smuxi is eating >500MiB RSS).
It seems that both of these problems could be resolved by not sharing this state between the frontend and the backend, and instead having a cursor-based interface between the frontend & backend. Then the frontend would only need to get the most recent page of text from the backend on connect, which should speed up that process. It would also reduce frontend memory usage, as the frontend would need to store less state.
Finally, it would allow the removal of the non-obvious distinction between “buffer lines” and “engine buffer lines”, and would make adding “unlimited” as an option more feasible.
Related issues
| related to Smuxi - Feature #901 | Client should round-robin sync with core's persistent buffers rather than doing an entire channel. | New | 11/03/2013 |
History
Updated by Mirco Bauer 5103 days ago
With regards to the memory usage you are seeing my Smuxi never uses more than ~50MB on X86 with 1000 buffer lines. I suspect GTK+ or the theme plays a role here.
Updated by Mirco Bauer 3993 days ago
- Category changed from Common to Frontend GNOME
The engine already DOES provide the needed APIs to dynamically load chunks of messages but the frontend is just fetching the last XXX and that's it.
Updated by Mirco Bauer 3498 days ago
Mirco Bauer wrote:
The engine already DOES provide the needed APIs to dynamically load chunks of messages but the frontend is just fetching the last XXX and that's it.
I have to amend this statement. The IMessageBuffer API [0] does not allow to fetch the last 100 messages and then the next 100 message of that, this has to be addressed first before the feature can be implemented in the frontend.
https://github.com/meebey/smuxi/blob/master/src/Engine/MessageBuffers/IMessageBuffer.cs#L28Updated by Mirco Bauer 3498 days ago
- Subject changed from Cursor-based frontend/backend communication to Cursor-based frontend/backend communication / dynamic backscroll
Updated by Mirco Bauer 1768 days ago
I started a prototype in a git branch to change the MessageBuffer API, to use timestamp+counter instead of naive/non-reliable index offset to identify and fetch a specific range of messages:
https://github.com/meebey/smuxi/compare/experiments/message_buffer_timestamps