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

[Andy Somerville]

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
> 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  -  Glade-devel at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/glade-devel
>
>
>