Re: [Glade-devel] Re: libglade vs glade for dialog generation

[Todd Fisher <toddf simosoftware com>]

Gus Koppel wrote:

> Hongli Lai wrote:
>
>  
>
> > > Let me briefly sum up, again. Using libglade + XML file instead of
> > > Glade generated code means, you
> > > - have more external library dependancies,
> > >      
> > >- have higher disk space consumption
> > >- have greater installation package if it's to be self-contained
> >
> > Statically link to libglade. libglade isn't that big.
> >    
>
> It's not only libglade itself. There are three more libs equired if
> libglade is to be used, as I mentioned earlier. And static linking
> doesn't really reduce package size or required disk space, especially
> not if libglade is already installed on a system. Btw, if I follow LGPL
> (I think that's libglade's license, isn't it?) precisely, then static
> linking isn't covered by the license, as others have concluded already.
>
>  
>
> > And one can write a script/program to convert the bytes in the XML
> > file to a C array, similar to gdk-pixbuf-csource. Then you tell
> > libglade to parse the XML file from a variable instead of from a file.
> >    
>
> This would neither reduce the overall size of the package nor the
> performance penalty. If I have a Glade XML file which is so large (> 1
> MB), that opening dialogs is seriously delayed (1 - 2 seconds or even
> more), then this is not due to harddisk I/O but due to XML parsing.
> Linking the file statically into the application would increase access
> speed by some milliseconds only, but increase file size by exactly the
> size of the XML file (which is those >1 MB in my case). With Glade code
> my entire program (including interface.c and all other custom modules)
> is less than 1 MB in size, hasn't any further dependencies (which I find
> very convenient) and runs without delays, as with libglade + XML.
>
>  
Actually, i used the argument that xml parse time was a large pentity in 
loading a libglade app.  Because I was hoping to suggest that libglade 
should create cache files of the parsed .glade files, cutting that load 
time down (assuming the load time was the parse time).  But if you dig 
back deep enough in the email logs (say early 2004) you'll find a 
posting which puts the parse time for a .glade file in at around 10% of 
the total load time of a libglade/gtk+ app.  It also provides a test 
application for measuring the parse time and the widget construction 
time.  The bulk of the time is spent constructing the gtk+ widgets 90%.  
So, that would mean that libglade only increases the start up time of an 
app by a little say 1/100.    But wait you're probably saying this can't 
be.  My 1 meg .glade file takes for ever to load.  So, it is bad design 
to create glade files over a meg in size, because libglade's 
glade_xml_new function will process the whole file constructing every 
widget that file defines.  Rarely, however does an application ever need 
all the widgets constructed at one time to display to the user.  So, a 
better design is to have many small glade files for each part of the 
app.  This way they can be loaded when they are needed and quickly.  So, 
I really think that before we go off on the performance of a libglade 
app we really need to think about how the libglade app is being used, 
and we also need to see some measurements on the performance of loading 
a .glade file.  So, have a look at this thread:
http://lists.ximian.com/archives/public/glade-devel/2004-April/000579.html

> > > - have higher RAM conumption at application execution time
> >
> > I really doubt that matters compared to the rest of the app or the 
> > desktop.
> >    
>
> I believe such attitudes are to blame for ever-growing resource demands
> of desktop environments and applications, with sometimes hardly
> noticable benefits for the users. I don't follow it and I wish more
> programmers wouldn't do either.
>  
I believe it is bad design

> _______________________________________________
> gtk-app-devel-list mailing list
> gtk-app-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>