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

[Ian Monroe]

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). :)

Ian