[cmake-developers] Future of ccmake and cmake-gui
Jean-Michaël Celerier
jeanmichael.celerier at gmail.com
Thu Aug 17 05:31:48 EDT 2017
> For example, I've seen way too many
projects screw up with Brew because they fail to ship a binary that
can work on a clean user system who is not going to install Brew.
I must be lucky then, because just using macdeployqt copies all the
dependencies for me and
updates all the install paths correctly whether I use Qt's own build or
brew's.
> It pulls a new version of gcc instead of using Xcode/clang on
your system and builds an entire dependency chain based on GNU tools.
this is false. brew uses xcode & clang on your system.
> Similar problem for Windows...Visual Studio is the requirement.
I don't know if you are talking about Chocolatey or Qt but neither require
Visual Studio on windows.
Qt even comes with MinGW if you wish.
> And Mac doesn't have configure/autotools by defaul.
but... "configure" has nothing to do with autotools.
It's just a shell script (which is sometimes generated *from* autotools;
this is not the case with Qt AFAIK).
> and I never figured why Qt's RAM consumption footprint is so high...based
on all the DLL binary code it
has to load, or something more intrinsic to its implementation.
science can help us here :p two tools are very nice for this :
* bloaty mcbloatface for binary bloat
for file in /usr/lib/libQt5*.so ; do (echo $file; bloaty $file| grep
-A3 'text') ; done
tells us stuff like
/usr/lib/libQt5Core.so
55.4% 2.75Mi .text 2.75Mi 55.5%
23.5% 1.16Mi .rodata 1.16Mi 23.5%
7.3% 372Ki .eh_frame 372Ki 7.4%
4.1% 210Ki .dynstr 210Ki 4.2%
/usr/lib/libQt5Gui.so
70.0% 3.82Mi .text 3.82Mi 70.2%
7.8% 438Ki .eh_frame 438Ki 7.9%
6.1% 342Ki .dynstr 342Ki 6.1%
5.1% 286Ki .rodata 286Ki 5.1%
A bit surprising to see .eh_frame; I thought Qt was compiled with
-fno-exceptions but maybe that's just my distro.
Quite a bunch of .rodata in Qt5Core too, I wonder why.
Further examination through
readelf -x .rodata /usr/lib/libQt5Core.so | less
seems to show up a lot of locale-specific calendar text & such, e.g. names
of the months in twenty languages, currencies, time zones, etc
* And then, runtime examination: for this I tried making a minimal gui
program:
#include <QApplication>
#include <QMainWindow>
int main(int argc, char**argv)
{
QApplication app(argc, argv);
QMainWindow w;
w.show();
return app.exec();
}
compiled with
g++ -DQT_NO_DEBUG -fPIC -I/usr/include/qt/ -I/usr/include/qt/QtCore
-I/usr/include/qt/QtWidgets -I/usr/include/qt/QtGui main.cpp -lQt5Core
-lQt5Widgets
and then use the wonderful Heaptrack (https://github.com/KDE/heaptrack) :
heaptrack ./a.out
which then greets us with http://imgur.com/a/eYjaL
As you can see, "peak heap memory consumption" is at a bit less than 400
*kilobytes*. So the Qt memory usage that you see is clearly due only to
binary bloat.
And indeed (sorry for shitty bash skills):
$ ldd a.out | cut -d '=' -f1 | awk '{print "/usr/lib/" $1;}' | xargs
readlink | awk '{print "/usr/lib/" $1;}' | xargs du -csh | sort -h
16K /usr/lib/libdl-2.25.so
16K /usr/lib/libXau.so.6.0.0
24K /usr/lib/libXdmcp.so.6.0.0
32K /usr/lib/librt-2.25.so
64K /usr/lib/libdouble-conversion.so.1.0.0
68K /usr/lib/libbz2.so.1.0.6
72K /usr/lib/libGLX.so.0.0.0
72K /usr/lib/libXext.so.6.4.0
80K /usr/lib/liblz4.so.1.7.5
84K /usr/lib/libgpg-error.so.0.22.0
92K /usr/lib/libz.so.1.2.11
144K /usr/lib/libpthread-2.25.so
152K /usr/lib/liblzma.so.5.2.3
164K /usr/lib/libxcb.so.1.1.0
176K /usr/lib/libgraphite2.so.3.0.1
216K /usr/lib/libpng16.so.16.31.0
444K /usr/lib/libpcre2-16.so.0.5.0
460K /usr/lib/libpcre.so.1.2.9
536K /usr/lib/libsystemd.so.0.19.0
548K /usr/lib/libharfbuzz.so.0.10400.5
552K /usr/lib/libGL.so.1.0.0
600K /usr/lib/libGLdispatch.so.0.0.0
796K /usr/lib/libfreetype.so.6.14.0
1,1M /usr/lib/libglib-2.0.so.0.5200.3
1,1M /usr/lib/libm-2.25.so
1,2M /usr/lib/libgcrypt.so.20.2.0
1,3M /usr/lib/libX11.so.6.3.0
1,7M /usr/lib/libicuuc.so.59.1
1,9M /usr/lib/libc-2.25.so
2,5M /usr/lib/libicui18n.so.59.1
5,0M /usr/lib/libQt5Core.so.5.9.1
5,5M /usr/lib/libQt5Gui.so.5.9.1
6,4M /usr/lib/libQt5Widgets.so.5.9.1
12M /usr/lib/libstdc++.so.6.0.24
26M /usr/lib/libicudata.so.59.1
69M total
So there's 17 megabytes of Qt in here; hopefully the rest would already be
loaded by your system.
Best,
Jean-Michaël
On Thu, Aug 17, 2017 at 3:34 AM, Eric Wing <ewmailing at gmail.com> wrote:
> On 8/16/17, Jean-Michaël Celerier <jeanmichael.celerier at gmail.com> wrote:
> > @Eric Wing
> >> I am not making a strong push for this, but I want to bring it up to
> > at least get people thinking about this... I am disturbed by the size
> > and complexity of Qt. My past experiences have not been good and I
> > find it a massive chore to get an environment setup (especially on Mac
> > and Windows...and building Qt on Raspberry Pi is a nightmare).
> >
> > Really ? On mac it's just brew install qt. On windows choco install
> qt-sdk
> > (and it even comes with mingw so that you don't necessarily have to
> install
> > visual studio).
> > On Raspberry sudo apt-get install qtbase5-dev.
> >
>
> So 3rd party package systems are banned for me. They cause too many
> dependency problems themselves. For example, I've seen way too many
> projects screw up with Brew because they fail to ship a binary that
> can work on a clean user system who is not going to install Brew.
> Also, it causes needless redundancy and changes the toolset if I
> recall. It pulls a new version of gcc instead of using Xcode/clang on
> your system and builds an entire dependency chain based on GNU tools.
> Similar problem for Windows...Visual Studio is the requirement.
>
> As for Pi, I think the problem I had was the Qt available in the repo
> at the time was too old for me. (Typical Debian long release cycle
> problem.)
>
> But I still consider it a problem if these things are too hard to
> build because (especially for me) there is always a new platform that
> needs to be ported to.
>
>
> > Building qt itself is a matter of doing (cue errors from typing in a mail
> > without checking)
> >
> > git clone https://github.com/qt/qt5
> > cd qt5 ; git submodule update --init qtbase ... # whatever submodules you
> > need
> > ./configure -open-source -confirm-license -nomake tests -nomake examples
> > -prefix /opt/my-qt
> > make -j8 && make install
> >
>
> My last experience was that there were critical bugs in the Qt Mac
> release at the time (and this was the official binary release). And
> Mac doesn't have configure/autotools by defaul. Again...no brew for
> various reasons like above.
>
> >
> > Maybe consider a LTCG build (-ltcg) if this really matters ? This way I
> can
> > get a moderately complex GUI app that uses gui, widgets, network, qml,
> > etc...
> > under ten megabytes, so something like cmake-gui should be way smaller...
> > (this also removes any problem related to DLLs).
>
> I wouldn't be able to say. And I never figured why Qt's RAM
> consumption footprint is so high...based on all the DLL binary code it
> has to load, or something more intrinsic to its implementation.
>
>
> -Eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170817/24af335d/attachment-0001.html>
More information about the cmake-developers
mailing list