[Development] QtCore is 2 MB larger in Qt 5

[Olivier Goffart]

On Friday 13 July 2012 13:11:15 Giuseppe D'Angelo wrote:
> Random thoughts:
> 
> On 11 July 2012 20:22, Thiago Macieira <thiago.macieira at intel.com> wrote:
> > That's 63% bigger.
> > 
> > Top 20 culprits:
> > 
> > 251684 .obj/release-shared/qrc_mimetypes.o:.rodata 0x3d724 0x0
> 
> Are the mimetypes alwasy included, even on GNU/Linux systems that are
> supposed to have them around (in a "standard location")? That is: is
> there a way to build QtCore w/o the mimetype data?

It is a huge xml file that is embedded on that resource.
Maybe we could just store it compressed. (and uncompresed with 
QByteArray::uncompress).
It would be slower, but that file is only used when it is not found on the 
system.
We could also store a pre-parsed version.
Another option would be to ship it with Qt, but as a separate file, not in the 
resource.

Could be done in Qt 5.1
 
> > 157528 .obj/release-shared/pcre16_exec.o:.text 0x26758 0x0
> > 113101 .obj/release-shared/pcre16_jit_compile.o:.text 0x1b9cd 0x0
> > 60384 .obj/release-shared/pcre16_ucd.o:.rodata 0xebe0 0x0
> > 43088 .obj/release-shared/pcre16_compile.o:.text 0xa850 0x0
> > 26408 .obj/release-shared/pcre16_dfa_exec.o:.text 0x6728 0x0
> 
> This is indeed something (~400K!). Unfortunately PCRE uses its own set
> of unicode tables (_ucd.o) fine tuned for what it does, i.e. it
> doesn't support (for now) ICU or any similar library. The good news is
> that QtCore will dynamically link to PCRE if it's found on the OS,
> thus not having this code size increase. 

> (Note that we require quite a
> recent version, so only a few systems already provide the one we need).

Distributions will upgrade their PCRE version as they upgrade Qt.

> 
> > 57900 .obj/release-shared/qeuckrcodec.o:.rodata 0xe22c 0x0
> > 134944 .obj/release-shared/qbig5codec.o:.rodata 0x20f20 0x0
> > 133792 .obj/release-shared/qjpunicode.o:.rodata 0x20aa0 0x0
> > 117842 .obj/release-shared/qgb18030codec.o:.rodata 0x1cc52 0x0
> 
> Codecs linked in instead of in plugins or what?

Yes.
https://codereview.qt-project.org/#change,12955
The problem is that codecs in plugin do not really work as we need codecs to 
load plugin (in order to convert the paths, and so on)
What Qt did is to consider everything as latin1 before they were loaded. But 
this was not working well.

In the long term, Qt should not have its own code for all those codecs, but 
rely on the platform libraries.


> > 51877 .obj/release-shared/qsortfilterproxymodel.o:.text 0xcaa5 0x0
> > 36993 .obj/release-shared/qitemselectionmodel.o:.text 0x9081 0x0
> 
> Move from QtGui, i.e. QtGui decreased :-)
> 
> > 26803 .obj/release-shared/qmimeprovider.o:.text 0x68b3 0x0
> > 20335 .obj/release-shared/qregularexpression.o:.text 0x4f6f 0x0
> > 16649 .obj/release-shared/qstandardpaths_unix.o:.text 0x4109 0x0
> 
> New public API...

Exactly...  Bigger is Better, right? ;-)


> 
> No idea about the remaining parts, but thank you for the stats. It's
> something interesting to talk about.

-- 
Olivier

Woboq - Qt services and support - http://woboq.com