ext Dusan Zatkovsky skrev:
> My second question is about lib dir in qtjambi jar. What is compiled in 
> libxcom_trolltech_qt_gui.so? I thought that it is only 'wrapper' around 
> libQtGui.so, but it is _bigger_ than libQtGui.so.
>
>   

Yes, that's the bindings library for QtGui. On Windows it's about half 
the size of QtGui, while it's a little bit bigger than QtGui on Linux.

I'd say the size on Windows is mostly due to the fact that the manual 
signature mangling needed for JNI to work properly creates very long 
function names, thus making the symbol table very large. All inline 
functions will also be inlined into the bindings library and not into 
QtGui.dll, which probably contributes some to the relative size. The 
rest of the code is glue code, converting types back and forth and book 
keeping.

In the past, we've experimented with ways of reducing the overhead of 
the bindings library. One way would be to reduce the number of JNI 
functions by using call tables. E.g. you could easily generate a single 
exported JNI function per function signature which would in turn call a 
non-exported, more specific function based on an index you pass in. This 
should have some impact, since there are only so many unique function 
signatures in Qt. There's actually a *very experimental*, undocumented 
feature in the Qt Jambi Generator that you can try out by passing 
"-native-jump-table" to the generator. This feature hasn't been 
maintained, and is likely to break at the moment, though, so be prepared 
to get your hands a little bit dirty =)

Another way to reduce the size would be to have the generator refactor 
some of the boiler plate code into separate functions, since there's a 
lot of duplicate conversion code spread around the library. I think 
you'll gain the most from optimizing the symbol table, though.

I'm guessing the reason it's so much bigger on Linux is twofold: 1. The 
default symbol visibility in gcc causes all functions in the 
QtJambiShell_QFooBar-classes to be exported, even though they are never 
needed externally. And 2. Visual C++ outperforms gcc when it comes to 
optimization.

To remedy the symbol visibility issue, it should be possible to use the 
"strip" command to remove the entries for unneeded functions, thus 
reducing the footprint of the bindings library substantially.

-- Eskil



_______________________________________________
Qt-jambi-interest mailing list
[email protected]
http://lists.trolltech.com/mailman/listinfo/qt-jambi-interest

Reply via email to