[Kde-bindings] Splitting up the Smoke qt library into modules

[Richard Dale]

On Friday 23 October 2009 02:57:24 pm Ian Monroe wrote:
> On Fri, Oct 23, 2009 at 6:46 AM, Richard Dale <rdale at foton.es> wrote:
> > On Thursday 22 October 2009 11:16:58 am Ian Monroe wrote:
> >> On 10/21/09, Richard Dale <rdale at foton.es> wrote:
> >> > While we're discussing BIC changes to the smoke libs, I wonder if it
> >> > would be
> >> > a good idea to split up the libsmokeqt library into small libs. The
> >> > small size
> >> > of the Smoke libs is becoming a big advantage relative to other
> >> > bindings libraries, and it we split them up a bit maybe the advantage
> >> > would  be larger
> >> > still. Or is the a performance tradeoff in that searches for a class
> >> > or method
> >> > would have to cross Smoke module boundaries more often and that would
> >> > slow things down? It is worth measuring somehow?
> >> >
> >> > For a start I really thing we should remove QtXml and QtSql from the
> >> > base Smoke library as nearly all dynamic languages have their own
> >> > versions of there
> >> > which are quite likely to be better than a wrapped C++ version. For
> >> > example, there in no point in using the QtSql classes in Ruby because
> >> > Rails ActiveRecord is so much better.
> >> >
> >> > Then the decision is whether it is a good idea to map one Qt module
> >> > onto one Smoke library.
> >>
> >> Would it make sense to split up qtgui? a basic module, a qgv module
> >> and the rest for instance. QtGui is just sooo much bigger then any
> >> other module, but like I'm guessing most amarok scripts use a fairly
> >> limited subset (and other users of smoke are probably in the same
> >> boat.)
> >
> > Now I've created smoke libs for qtcore, qtnetwork and qtgui I know their
> > sizes:
> >
> > qtcore: 0.79 Mb
> > qtnetwork: 0.31 Mb
> > qtgui: 3.1 Mb
> >
> > So by the time you are using qtcore and qtgui it is nearly 4.0Mb and only
> > 0.4Mb less than the complete qt smoke lib was. So I'm not sure we save
> > much on the loading of the smoke lib itself, it is more that we don't
> > need to load the libraries that unused Qt modules depend on. For
> > instance, QtOpenGL will probably pull in a load of 3D classes as well as
> > the Qt lib itself, even though the actual smoke lib for qtopengl will
> > probably be quite small.
> >
> > I think splitting off qgl is just overcomplicating things, and because it
> > has to load QtGui anyway I don't think we would save much. I think we
> > need to try the QtScript binding with the qt-all smoke library, and then
> > compare it with just qtcore+qtgui and see if it seems to make any
> > difference to start up time.
> >
> >> Would want to proceed with some real data to decide what is basic,
> >> maybe write some scripts to count class usage in various users of
> >> smoke.
> >>
> >> We should perhaps delay this decision until we know what the cost of
> >> splitting is. Just putting the idea out there.
> >
> > Yes, if you could do some actual measurements of Amarok loading the
> > bindings, and comparing the time taken and memory usage with the full
> > lib, and the split up libs, that would be really useful, not just for the
> > QtScript bindings.
> 
> Well what I meant was, to see what gui classes are used the most to
> create a list of "most used gui classes" which we could use to split
> off a qtgui-essential library.
> 
> But regardless benchmarking various approaches in amarok is a good
> idea. I'll try to get to that.
> 
> I wonder if we created some smart code (in js or in c++) to let script
> writers hold off on loading a module until they actually use it, that
> would be useful. The use case here is for Lyrics scripts that load on
> startup, but don't need to do any XML parsing until someone requests a
> lyric. Or maybe just some documentation that they should do it this
> way, since I'm guessing it wouldn't be hard (just load qtxml in very
> function that needs it... won't cost anything the second time). :)
We're changing the smoke libs so the have an extern "C" interface to allow 
them to be dlopen'able. So maybe we could load the XML QtScript plugin but not 
load the corresponding Smoke plugin lib until one of the XML classes is 
accessed?

-- Richardd