We were looking at the time and
memory costs of libglade, and are particularly concerned about the cost of the
XML parser. While it might be possible to reduce the cost (by going to a
SAX-based parser, or requiring simplified-XML) parsing is still being
performed.
What would the reaction be to a
pre-compiled Glade format? A simple compiler (we have a prototype knocked
together with Perl) would read the Glade XML, translating it into pre-parsed
byte-code that describes the widget tree in a very lean format. A separate
run-time would be needed to instantiate a widget tree from the compiled
format, however the amount of code needed is greatly
reduced.
(An obvious question is "what about Fast
Infoset", or other related binary or compressed XML techniques: those systems
still preserve the full expressiveness of XML. In this case, we don't see the
need for that expressiveness on the run-time side. Our desire is only to
instantiate Gtk widgets as fast as possible. Hence, converting to a non-XML,
specialized format, becomes attractive.)
The simpler the format, and the
more work that is done on the compiling side, the less time it takes to
instantiate the widgets. No XML parsing needs to be done at run-time. This can
also remove the need for character set conversions, if you deem the compiled
format to always be stored in UTF-8.
Version compatibility issues can
be ameliorated by storing both the original Glade XML file and a compiled glade
file in an app's resources: a fallback to libglade would always be possible if
the compiled format isn't appropriate. Since the compiled format can be
significantly smaller than the XML (since it is simply less verbose) the storage
cost would be minimal.
(A very quick and dodgy test suggested
that a compiled glade file would be under a quarter the size of
the XML version, and the run-time to load the compiled glade code could be
extremely tiny, on the order of a few dozen K).
Given some of the discussions
about Glade3 and GTK changing to directly support loading Glade files, we
thought we should mention this idea to the group now. We're probably going to
implement something along these lines in any case (as a stand-alone Glade XML
translator), but would be interested in collaborating on a
design.
Our interests are on an
embedded platform, where we have severe constraints on memory and speed, however
it seems possible that this approach could provide benefits even with desktop
Gtk apps.
Please respond with any comments, questions, or
concerns, as well as ideas of what other forums would be appropriate to
which to send this RFC.
- Jeff Westerinen
-- PalmSource,
Inc.
_______________________________________________ Glade-devel maillist - [email protected] http://lists.ximian.com/mailman/listinfo/glade-devel
