[Glade-devel] Request For Comments: a proposal for an alternative to libglade

[Jeff.Westerinen at palmsource.com (Jeff Westerinen)]

    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.
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/glade-devel/attachments/20060727/ce8911ec/attachment.html