QML big memory consumption?
-
Hay,
bq. Are you saying the program runs out of memory?
Yes my developed application eventually runs out of memory on the embedded platforms. We have 140Mb of ram in total to run our application. If I monitor the system memory of my embedded device I see the memory increasing until 110 Mb with all possible components and screens loaded until now, this is concerning since not everything is developed yet.
bq. What made you do it? (to unload the screens)
some components we use are only used at startup level like progressbar and animated startup. So it was a hope unloading would free the used memory of that. It is interesting to know that it caches the components. Do you know if this is usual that we use that amount of memory with the qt quick components? Do you perhaps know what components allocated that much memory?
bq. And what does the OS think you are using in memory-count?
the memory count that the system indicates is relatively the same as the monitor inside the application. On the embedded device system monitor is the only thing we have but it is also the only application running in user space.
-
You may want to try QDeclarativeEngine::clearComponentCache() after your intro screens have been unloaded.
-
Today I experimented a bit with the ClearComponent cache after my startup procedure, but unfortunatly i dont see many difference in memory allocation. Some kb are freed against the many Mb. When i launch the sample qml application and follow the trace to qmalloc i see that a huge allocation takes place of the qfont engine. Do yo know how we can save memory on that part?
Here is a trace of the call with alloc over 1Mb.
QtCored4.dll!qMalloc(unsigned int size=112202) Line 57 C++
QtCored4.dll!QByteArray::resize(int size=112182) Line 1415 + 0xc bytes C++
QtGuid4.dll!QFontEngine::getSfntTable(unsigned int tag=1801810542) Line 728 C++
QtGuid4.dll!QFontEngine::loadKerningPairs(QFixed scalingFactor={...}) Line 806 + 0x11 bytes C++
QtGuid4.dll!QFontEngineWin::getCMap() Line 218 C++
QtGuid4.dll!QFontEngineWin::QFontEngineWin(const QString & name="Open Sans Extrabold", HFONT__ * _hfont=0x580a26ee, bool stockFont=false, tagLOGFONTW lf={...}) Line 344 C++
QtGuid4.dll!loadEngine(int script=0, const QFontDef & request={...}, HDC__ * fontHdc=0x00000000, int dpi=96, bool rawMode=false, const QtFontDesc * desc=0x004ce62c, const QStringList & family_list=[4]("Open Sans Extrabold","MS Shell Dlg 2","MS Sans Serif","")) Line 915 + 0x47 bytes C++
QtGuid4.dll!loadWin(const QFontPrivate * d=0x0203a348, int script=0, const QFontDef & req={...}) Line 1072 + 0x2d bytes C++
QtGuid4.dll!QFontDatabase::load(const QFontPrivate * d=0x0203a348, int script=0) Line 1119 + 0x11 bytes C++
QtGuid4.dll!QFontPrivate::engineForScript(int script=0) Line 305 + 0xd bytes C++
QtGuid4.dll!QTextEngine::fontEngine(const QScriptItem & si={...}, QFixed * ascent=0x0696ca34, QFixed * descent=0x0696ca30, QFixed * leading=0x0696ca38) Line 1936 + 0x13 bytes C++
QtGuid4.dll!QTextEngine::shapeTextWithHarfbuzz(int item=0) Line 1195 + 0x30 bytes C++
QtGuid4.dll!QTextEngine::shapeText(int item=0) Line 938 C++
QtGuid4.dll!QTextEngine::shape(int item=0) Line 1452 C++
QtGuid4.dll!QTextLine::layout_helper(int maxGlyphs=2147483647) Line 1753 C++
QtGuid4.dll!QTextLine::setNumColumns(int numColumns=2147483647) Line 1542 C++
QtGuid4.dll!QTextLayout::createLine() Line 817 C++
-
simple answer to your question; use a smaller font.
For instance there are apps out there that remove all the glyphs in a font you dont use. All the cyrillic ones when you have an english app, for instance. -
I'd definitely be interested in seeing what is causing most of the allocations. I assume that most of it is not in the font engine: although that will surely cause a large chunk to be allocated on application startup, it's unlikely to increase in an unbounded fashion.
With images, what is most likely happening is the image is being cached in the QDeclarativePixmapCache and not being released. We added API to scrub the cache in QtQuick2, not sure if it was backported to QtQuick1 or not.
In your simple rectangle + text example, the Loader element constructs a new component every time the source is reset and set again. If this component is parented to the engine, but never manually deleted by the loader during source reset, then it will stay alive forever. I'd be surprised if such a bug existed in Loader, but who knows - it's worth checking.
What does valgrind say about usage? When you exit the application normally, does valgrind report any leaks? If not, then I'd suggest that most of the memory is being used by JSC's heap (QtQuick 1.x, yeah?) - JSC heap gets torn down correctly on application exit, so valgrind won't report a leak, even though the JSC gc doesn't do much at runtime :-/
Anyway, more information is always good. With more detailed traces and analysis some solution might become apparent, but right now it's difficult to tell exactly what might be going on.
Cheers,
Chris. -
When I've reported long time ago a bug, that the simplest Qt application (only with main.cpp generated by QtCreator and one QML file with only one rectangle) produces 3000 lines of Valgrind outtput. I've received response that this is not the simplest Qt application...
Are you guys really willing to help?
Please notice that maresb has attached the source code! -
Hi kappa,
What do you want help with? What bug did you encounter?
Note that maresb's code is written for Qt Quick 1. Qt Quick 2 has a brand new engine that has much better performance than Qt Quick 1.
-
My problems are more or less the same as maersb's. But if you say, that there is no other way than change to Qt 5, then I will try with porting my application.
-
I know that when Qt Quick 2 came out, it was already far more efficient than Qt Quick 1, resource-wise. I also know that Qt 5.2 introduced further massive memory improvements to Qt Quick 2.
However, I don't know if porting is enough to resolve your issues. I also don't know if it's possible to fine-tune your app enough that it works with Qt Quick 1, because you haven't shown us your code.
(If I were to guess though, I'd say that porting to Qt 5.2.1 or later is your best bet)
-
I don't know if there are any performance comparison charts for Qt/QML apps (maybe one will create some, who knows), but I have currently two Qt Quick 2 apps and they usually use 40-60 Mb memory and not more, they are text, image and network heavy and use multiple screens and stuff, so not the simplest app every I would say.