MemoryConsumption
From AbiWiki
Contents |
Runtime Memory Consumption Issues
Place content here related to AbiWord memory consumption.
Contents
AbiWord has recently been mentioned in conjuction with the OPLC project. Together with the focus on embedded devices (e.g. the Maemo port) this is seen as a motivation to reduce memory consumption by some developers.
Document filter improvements
The import filter code is only used when opening a document (except for RTF which is involved in copy/paste). The idea is to have each import and export filter in a separate shared library and only load them on demand. The properties of each filter could be described in a ini-style key/value file.
At the moment AbiWord can use expat or libxml for document import. Maybe some bytes could be saved by using the glib builtin gmarkup parser as a third compile-time option. (needs investigation, gmarkup might not support enough of the xml standard for e.g. the ODF filter)
Layout Engine
There is overhead associated with the fp_TextRun class, which represents text internally in the layout engine; each instance of fp_TextRun requires around 200 bytes. The fp_TextRun always represents text of homogenous properties both in terms of formatting (e.g., bold/italics, etc.) and, where doing complex script processing, also in terms of directional properties as defined by the Unicode bidirectional algorithm. The latter means that a single instance of fp_TextRun represents a single item that is produced by the itemisation stage of complext script processing; in practical terms this would typically be one word, and this makes the overhead very significant.
There are two ways of reducing the memory requirements. First is by finding ways of reducing the overhead of the fp_TextRun class; the second is by refactoring the code, so that fp_TextRun could represent an arbitrary number of items. The latter would make it possible to reduce the number of runs on each line; assuming a line of homogenous format containing 30 words, the overhead saving for that line would be some 11kB. There is currently some code in the layout engine that tries to reduce the number of instances of fp_TextRun, but it comes with significant processing overhead, and occasionally undesirable side effects; it would be worth exploring a different way of handling this, possibly moving the itemisation stage of the complex script processing from the fl_BlockLayout class into fp_TextRun.
Contributors
- Main.RobertStaudinger - 25 Nov 2005
- Main.TomasFrydrych - 25 Nov 2005
