Cut down memory to 8 bytes per cell
By egm... on October 01, 2010 21:46 (imported from Google Code)
Currently iTerm uses 12 bytes for each character cell, see screen_char_t in LineBuffer.h:
- 2 bytes for the Unicode character
- 2 bytes padding for alignment (soon to be taken by 4 bytes for Unicode)
- 4 bytes for bg_color
- 4 bytes for fg_color
I assume that bg_color and/or fg_color actually somehow encode other attributes (such as boldness). Still, it's a lot, and it could easily be shrunk down to 4 bytes for all the attributes, similarly to how Gnome-Terminal does, see http://git.gnome.org/browse/vte/tree/src/vterowdata.h:
- 9 bits for bg_color (256 colors, plus "default", "inverse of default" and a couple more)
- 9 bits for fg_color
- 1 bit for bold, underline, blink etc. each
- and probably a few more for whatever technical reason
Making this structure consist of 8 bytes instead of 12 would basically cut down iTerm's memory usage to two thirds.
I think with some more bitpacking it could also be squeezed into 6 bytes. Unicode, as far as I know, will never grow beyond 10FFFF which fits in 21 bits and leaves lot of room to denote special cases (e.g. continuation cell), 9+9 for color (with a dirty trick it could be 17 together), so there's room for 9 (maybe 10) attribute bits. Doing such bitpacking magic, and reading from non-aligned memory offset might however significantly slow down performance, so I'm not sure if it is a good idea, maybe one day we should try it out. [Note: in GCC, the magic to avoid padding is "attribute((packed))", not sure about whatever compiler is being used on Mac to compile iTerm.]