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

[Richard Dale]

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.

> > One example for me, is that I think a separate QtCore smoke library would
> > be useful for Semantic web applications, as I could use the Ruby bindings
> > for QtCore, Soprano with the ActiveRDF Virtuoso adaptor with Wt::Ruby for
> > the web
> > app without the overhead of the QtGui library.
> >
> > -- Richard
> > _______________________________________________
> > Kde-bindings mailing list
> > Kde-bindings at kde.org
> > https://mail.kde.org/mailman/listinfo/kde-bindings
> 
> _______________________________________________
> Kde-bindings mailing list
> Kde-bindings at kde.org
> https://mail.kde.org/mailman/listinfo/kde-bindings
>