Comment 12 for bug 1430620
Revision history for this message
| Egmont Koblinger (egmont-gmail) wrote | #12 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
73416ba
(Get the code!)
> Speed
Encryption added about 10% to the required CPU usage. Now, with in-memory scrollback, would you keep it encrypted or not? If so, you'd keep wasting CPU. If not, someone will come along and complain that it's been written to disk (swap) unencrypted and it leaks data. But other apps also can write their data to swap, and perhaps the whole swap partition should be encrypted (which is not free either), but it's out of vte's control. I really don't know the answer to this question.
> battery life
> energy use
Apart from encryption's CPU usage, do you have further information about it? What's the ratio between 1 second of CPU vs. 0.01 second of HDD usage? (More concretely: between numbers that correspond to VTE processing a given amount of scrollback vs. writing that amount of data to HDD or SSD?)
> SSD life
See above, I still believe it's a non-issue.
> privacy
Solved in vte-0.40.
I perfectly understand your feelings towards storing the scrollback in memory. What could push this feature request higher up on my priority list is if you could also support it with evidence (data).
It still looks to me that the typical amount that vte adds to cpu/energy usage, ssd life etc. are way below to be worried about. And if we're worried about cpu/energy, we should probably start the optimization somewhere else.
For start, could you please apply the patch and let me know how much data your g-t processes during let's say an average week? I have also installed it (replacing /tmp with my home dir, in case I'll reboot) and will share my numbers.