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

I think it would be worth while to have a compiled format alongside
the current method iff it was significantly faster. If you are going
to be doing it anyways, why not?

On 7/27/06, Jeff Westerinen <Jeff.Westerinen at palmsource.com> wrote:

    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

    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  -  Glade-devel at lists.ximian.com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]