[review] [PyKDE] PyQT module size

Brian Thomason brian.thomason at linspireinc.com
Fri Mar 4 02:45:28 GMT 2005


Many thanks for the kind replies all. 


Jim Bublitz wrote:

>I seem to recall the actual overhead for a fairly large program using several 
>PyQt modules and 5 or 6 PyKDE modules  is somewhere around 6-8MB according to 
>'free'. Another way to look at it is that the *first* app has a lot of 
>overhead, but each successive PyQt/PyKDE app has very little - use them 
>more :) 
>
:-)  Couldn't agree more.  We're up to about 6 pyqt/pykde apps in house 
now with two of them being somewhat complex. As you say, once one is 
loaded, the additional overhead for the other according to my simple 
tests is VERY nominal.

>Most of the code is pretty much a fixed amount of overhead per method and 
>that's written very efficiently by sip. The tradeoff then becomes size of 
>code vs. completeness of code - ie, the only way to make PyQt or PyKDE 
>smaller is by throwing out methods and classes. Throwing out methods is 
>possible; throwing out classes can eventually become a dependency nightmare.
>  
>
I'm not heading down that path at all.  That sort of thing always bites 
you in the rear in the future when you need a method you've stripped.

>In either case, it's pretty hard to take a general purpose development system 
>and predict what users will find useful or necessary down the road,
>
Exactly.  This isn't a possible solution for us.

>I've discussed this in the past, and the conclusion is usually "well, nobody 
>ever complains about it" - this is literally (to my knowledge) the first 
>complaint we've ever had. 
>
I'm not complaining, believe me ;-)  As far as Linux GUI development 
goes, I haven't found anything sweeter than this combination.

>It's a question of how much you're willing to "pay" 
>for the convenience of writing Qt/KDE code in Python, and it seems like the 
>"market price" in KB is pretty high (and memory is pretty cheap).
>  
>
Agreed.  I'm willing to pay quite a high price myself in most instances, 
as the tradeoff to coding most UI stuff in C++ these days isn't worth it 
IMHO.  The problem comes into play on low-end boxes targeted at newbie 
users, which is, fortunately and unfortunately, our  target these days.

>There are ways that a custom set of bindings could be developed for your 
>applications that only expose the methods/classes from PyQt/PyKDE that you 
>really need. It would involve writing a custom set of C++ wrappers for the 
>PyQt/PyKDE APIs and then binding those. Depending on what you need, that 
>could be as small as a few hundred K for everything. For an application of 
>any complexity (eg menus/toolbar/statusbar and a selection of various 
>widgets, std file dialogs, etc) it might turn out to be quite a bit of work 
>though, and the resulting names wouldn't "look" like Qt/KDE anymore.
>
>  
>
That wouldn't work out either then.  LSongs is quite complex, which is 
really the only one we're truly concerned about. (Some would say bloated 
;-) )

I think I'm just going to go with the other users' recommendation of 
nabbing the latest sip and compiling with some different flags with GCC4 
and see if that gets me some quick wins.  My mind is too small and 
fragile to attempt the changes you proposed above without screwing 
things up or causing myself more time than its worth (Thanks just the 
same for the options though) Which is kind of how I view pyqt in general 
- A time saver.

I do have one last question for you though.  One user seemed to purport, 
and I haven't tested hard enough yet to confirm it, that when two python 
strings are concatenated:

x = x + y

That a new string is created, leaving the old reference to x in memory.  
With python's garbage collection as it is, this doesn't seem to be 
correct, but I wanted to ensure there wasn't some special way of 
handling cleanup that I need to take into account.

Thanks again for all the help guys,

Brian

>Jim
>  
>

--

This message contains information which may be confidential and privileged. Unless you are the 
addressee (or authorized to receive for the addressee), you may not use, copy or disclose to anyone 
the message or any information contained in the message. If you have received the message in error, 
please advise the sender and delete the message.  Thank you.




More information about the PyQt mailing list