Subject: Footprint
From: Aaron Lehmann (aaronl@vitelus.com)
Date: Wed Dec 20 2000 - 15:34:39 CST
On Wed, Dec 20, 2000 at 08:23:44AM -0500, Thomas Fletcher wrote:
> Yes well we might have some fat trimming to do first. Our footprint
> (both runtime and exectable size) are a little on the big size ...
> we might be smaller than others, but we aren't _that_ much smaller =;-)
> Adding in things like STL and additional libraries (ie this psion
> library) doesn't help either.
Footprint has been something that I've been very concerned about. When
I did some profiling several months ago I found that about half the
footprint was due to the spelling dictionaries which are always
loaded. I don't know how the pspell stuff works, but here's how it
worked for ispell:
For some reason, the dictionaries are loaded in the initialization of
the _non-XP_ app class. That makes it much harder to fix since it has
to be fixed in many places. If the autospell preference item is off,
the dictionary should not be loaded at all until the user invokes a
spell check. And even then, it should be mmapped (on platforms that
support it).
Footprint is also quite execessive on large documents (see #1066).
This is probablt due to the formatter, which might be hard to fix.
> Has anyone given any thought to us using the Netscape Portable Runtime
> thingy so that we could make our importers/exporters work as plugins
> rather than having them bound directly into the executable. Never having
> written an importer or an exporter (though I'm tempted to look at a
> writing a WordPerfect one) how solid is our API and what are other
> people's thoughts on this?
I strongly believe that importers and exporters should be plugins that
are dynamically loaded. It makes little sense to have them in memory
100% of the time when they are only needed a .05% or less of the time
(during imports and exports). In fact, I belive that many features
should be in plugins. For some of my early thoughts on this, see
http://www.abisource.com/mailinglists/abiword-dev/99/February/0055.html.
As for NSPR: *shudder*. To me, mozilla spells bloat.
$ find ~/src/mozilla/nsprpub -name '*.c' | xargs cat | wc -l
139076
Seems like nspr includes _way_ more than portable plugins. Plugins
are not hard... on Unix it's just a dlopen() and it shouldn't be too
much harder on other platforms. The harder thing is defining a plugin
API, which AFAIK nspr won't help us with. And we already have the
importer/exporter class heirarchy...
I suggest that we create a new XAP_Linker abstract base class that loads
plugins. Derived classes for a specific architecture can implement the
functionality. Unix seems pretty trivial. Mike, can you handle
Windows? Thomas, QNX? What about BeOS?
This archive was generated by hypermail 2b25 : Wed Dec 20 2000 - 15:38:03 CST