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 <[EMAIL PROTECTED]> 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 - [email protected] > http://lists.ximian.com/mailman/listinfo/glade-devel > > > _______________________________________________ Glade-devel maillist - [email protected] http://lists.ximian.com/mailman/listinfo/glade-devel
