On Tue, Sep 6, 2011 at 11:33 AM, <[email protected]> wrote: > 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. > Adding it to core certainly seems like a step backwards from greater modularization, where as this approach seems ideal to me. As a developer who would like to use QtCore, I would like it to remain pretty small. If I have projects that need the interpreter linking an extra library in seems fairly sensible.
Looking forward to seeing what you come up with. Marcus _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
