[Konsole-devel] [Bug 176974] High memory consumption when using Konsole for a longer time.

[Matthew Woehlke]

https://bugs.kde.org/show_bug.cgi?id=176974





--- Comment #37 from Matthew Woehlke <mw_triad users sourceforge net>  2009-06-08 23:59:04 ---
Short version:
Without actually testing it, I think the patch is good. There is maybe room for
further tweaking, but for the "level of invasiveness" I would still push the
current patch or something very similar for the short term. We all seem to
agree on RLE'ing the formatting and making the history into some sort of
line-array.

Long version:
> The difference is that my current solution does not use one big block but uses
> a QList to store a pointer to each line.

My intent was still to use some array structure (e.g. QList) to store lines,
just that each line is a compressed buffer containing both format and text in
one memory block. There is a slight savings in memory, also there is savings
from the only-what-changed format blocks. There is a penalty to extracting text
hunks e.g. for copying, and you don't save a /whole/ lot by combining buffers.
The improved efficiency painting is probably nice, but you can only take
advantage of that with direct access to the format buffer from the paint
routine. (And ideally you would want to apply that methodology /everywhere/,
including the content of the tty. Preferably in such a way that you no longer
even need to build the format block for the history buffer, because you already
have it built from the tty. You could certainly build all of that onto the
latest patch at a later date.)

> There is certainly room for improvement if you want to squeeze out the last
> bits:
> - convert everything to utf-8 (might save you another 50% in the best case)

How is text handed off to Qt for painting, or put on the clipboard?
Specifically, I wonder if you would lose anything converting to UTF-8, in which
case IMO this should simply be done ;-). (But... later, probably.)

> - use any kind of compression for character data (e.g. RLE)

Conversely, this would be horribly inefficient when you need to actually get
the text. You would need to allocate buffers for decompression, decompress,
etc. Probably not worth it?

> - store the actual raw output which was printed to konsole originally and
> re-interpret it when you need to paint it...

I actually considered that as well... but it wouldn't work very well. The main
advantage would be if you could correctly re-flow text, but that breaks quickly
(e.g. as soon as you throw anything tty-aware into the mix, /especiallly/
curses applications). And if you only store format-change codes, I think the
ANSI format-change codes end up being just as many, or possibly /more/, bytes
than simply storing the format changes.

Something else I noticed; I *think* Konsole remembers the difference between
16-color codes (ANSI), 256-color codes (xterm), and 24-bit color codes
(Konsole). Which means that you should be able to pack most color changes into
fewer than 4 bytes; even into 1 byte for both fg/bg if they're ANSI.

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.