On 9/6/11 1:29 PM, "ext Thiago Macieira" <[email protected]> wrote:
>On Tuesday, 6 de September de 2011 12:12:10 [email protected] wrote: >> Yes, you're right that it adds some memory and startup overhead. The >> question that comes up is when you look at a whole system on whether >>this >> matters. If 95% of the apps anyway link to QtDeclarative or scripting in >> some way, it might not be a huge issue. >> >> The relocations you mention below might be fixable by using -Bsymbolic >>and >> -Bsymbolic-functions when linking QtV8. > >These numbers are with -Bsymbolic-functions already. > >Without it, the number of non-relative relocations would increase, but I >don't >think by much. There aren't many exported classes. > >The vast majority of these relocations are caused by the virtual tables >of >non-exported classes, with no exported base class: > > $ objdump -R libQtV8.so.5.0.0| awk '/__cxxabi/ || /__cxa_pure_virtual/{ >print >$3 }' | uniq -c > 525 _ZTVN10__cxxabiv120__si_class_type_infoE+0x0000000000000010 > 56 _ZTVN10__cxxabiv117__class_type_infoE+0x0000000000000010 > 2 _ZTVN10__cxxabiv121__vmi_class_type_infoE+0x0000000000000010 > 319 __cxa_pure_virtual > >This is caused by the code design: the visitor pattern that calls back >into >the the current class. > >I was just pointing out that it isn't free. But I agree that the impact >will >be there if people want to use QML anyway. > >It will just be nearly impossible convincing anyone not already using Qt >that >QtCore is acceptable (for example, to write system services on Linux). > >The major problem I have is that it makes any port to a new architecture >require 40k lines of code. Agree, the last two arguments are probably the most severe ones. A bytecode/p-code backend in V8 would really help here. The other option I've been discussing a bit with a few people would be to split libQtDeclarative into a part containing the engine (JS and QML) and one containing the graphical items. I don't think that would be problematic for anybody. The engine would then purely depend on QtCore (and maybe network). It doesn't give us everything, but is probably better than the current situation with the JS engine only being available with a Gui dependency. Kent and Jedrzej will look into this right now so we can get a clean split between the engine and the QML items. Let's see how we move on once that's done. Cheers, Lars _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
