Thanks for your suggestions, @J-Hilk

@J-Hilk said in Slow application with low CPU usage:

I would suggest emitting a signal, signalling data is processed, and then a mutex guarded getter function, that allows the other thread to access the required data.

I'm not sure I understand what you mean. Should each object have a mutex-guarded getter function? Should the objects be in different threads? In this case, wouldn't the emitted signal get queued?
I'd appreciate it if you could provide me an example and/or some material for further reading.

Another idea that has occurred to me is that I could use two threads, one for processing and one for GUI (this one updated just from time to time). Do you think it would make sense? My concern is that the processing thread must be fast enough to complete its cycle before a new piece of data comes in.
If this is the case, would it be necessary to use a mutex anyway?

Sounds like you should not be using QSerial and instead design a custom solution outside of Qt. Qt is not for real-time processing and your description of the task seems to imply real-time constraints.

@jeanmilost said in ListView - How to refresh rows which content changed without slowdown?:

view.model.dataChanged(view.model.index(0, columnCount - 1), view.model.index(rowCount - 1, columnCount - 1));

So you are emiting dataChanged from QML? That seems like a bad practice, why can't you do that in the model?

@JKSH

I did the download overnight anyway so I don't need further help resolving it, but I'll do that post on the Development mailing list to help others.

...unfortunately it is no longer possible to manually choose a mirror in the online installer.

Post the download speed you get from your default mirror, compared with the download speed you get from the best mirror you can find manually.

I'm confused, if I'm unable to manually choose the mirror in the installer, am I supposed to test my best mirror speed on the offline sources instead?

If I manually select http://mirrors.ocf.berkeley.edu/ today I can get ~1 MiB/s.

Presumably from the offline mirrors? Using the same mirror only gave me 330KBps.

The smallest possible download is a few hundred MB, which can be feasibly downloaded on a 200 KiB/s link.

The MSVC 2019 32 and 64 bit for Qt 5.15 are each 7GB so that's what I meant by smallest possible download.

@gde23 said in QTreeView with QSortFilterProxyModel extremly slow with many (~5000) items:

Thanks for demanding a minimal example :)

Thx for trying to create one - sadly a lot of people don't understand the demand for this but this here is a good example why it's needed :)

Hello,
I tried the library qwt and saw that the slowdown effect did not occur.
Update all my code to adapt it to the qwt library and once integrated, no type of slowdown occurs even after a couple of days. Also this library allowed me to insert better visual effects.

Thanks for the help.

@fem_dev said in Build with mingw32-make *very* slow:

First Question

Qt Creator starts to use jom, but I got this compile time errors:

09:35:09: The process "C: \ Qt \ Tools \ QtCreator \ bin \ jom.exe" exited normally. 09:35:09: Starting: "C: \ Qt \ Tools \ QtCreator \ bin \ jom.exe" -j4 jom 1.1.3 - empower your colors cd App / && (test -e Makefile || C: /Qt/5.15.0/mingw81_64/bin/qmake.exe -o Makefile C: /Users/VM/Desktop/rotortest/App/App.pro -spec win32- g ++ CONFIG + = debug CONFIG + = qml_debug) && C: \ Qt \ Tools \ QtCreator \ bin \ jom.exe -f Makefile C: \ Qt \ Tools \ QtCreator \ bin \ jom.exe -f Makefile.Debug 'C: \ Qt \ 5.15.0 \ mingw81_64 \ bin \ uic.exe' ../../rotortest/App/app.ui -o ui_app.h The syntax of the file name, directory name, or volume label is incorrect. jom: C: \ Users \ VM \ Desktop \ build-rotortest-Desktop_Qt_5_15_0_MinGW_64_bit-Debug \ App \ Makefile.Debug [ui_app.h] Error 1 'C: \ Qt \ 5.15.0 \ mingw81_64 \ bin \ uic.exe' ../../rotortest/App/custom_widget/value_unit.ui -o ui_value_unit.h 'C: \ Qt \ 5.15.0 \ mingw81_64 \ bin \ uic.exe' ../../rotortest/App/form/form_assembly.ui -o ui_form_assembly.h 'C: \ Qt \ 5.15.0 \ mingw81_64 \ bin \ uic.exe' ../../rotortest/App/form/form_excitation.ui -o ui_form_excitation.h The syntax of the file name, directory name, or volume label is incorrect. The syntax of the file name, directory name, or volume label is incorrect. jom: C: \ Users \ VM \ Desktop \ build-rotortest-Desktop_Qt_5_15_0_MinGW_64_bit-Debug \ App \ Makefile.Debug [ui_form_assembly.h] Error 1 jom: C: \ Users \ VM \ Desktop \ build-rotortest-Desktop_Qt_5_15_0_MinGW_64_bit-Debug \ App \ Makefile.Debug [ui_value_unit.h] Error 1 The syntax of the file name, directory name, or volume label is incorrect. jom: C: \ Users \ VM \ Desktop \ build-rotortest-Desktop_Qt_5_15_0_MinGW_64_bit-Debug \ App \ Makefile.Debug [ui_form_excitation.h] Error 1 jom: C: \ Users \ VM \ Desktop \ build-rotortest-Desktop_Qt_5_15_0_MinGW_64_bit-Debug \ App \ Makefile [debug] Error 2 jom: C: \ Users \ VM \ Desktop \ build-rotortest-Desktop_Qt_5_15_0_MinGW_64_bit-Debug \ Makefile [sub-App-make_first] Error 2 09:35:10: The process "C: \ Qt \ Tools \ QtCreator \ bin \ jom.exe" exited with code 2. Error while building / deploying project rotortest (kit: Desktop Qt 5.15.0 MinGW 64-bit) When executing step "Make"

How can I fix it?

My system:

Qt Creator 4.12.4 (GCC based - downloaded by MSYS2) Qt 5.15.0 Windows 10 x64 Mingw-w64 jom

Should be completely irrelevant. When your make file works with mingw-make, it has to work with jom as well. jomis a replacement for nmake because it did not allow -j parameter. AFAIK the MSVC does support directly multi-threading and it is not done through nmake.

Besides possible side effects through parallel access to the same file or whatever, there is no difference for compilation. You are listing compile errors which are due to the compiler you are using.

Second question

@koahnig said in Build with mingw32-make *very* slow:

Mingw-make does support now multi-threading. I did some tests back then, but after a reinstall, there was no need anymore.

Are you saying that you compiled your Qt project using the default MSYS2 Mingw-64 configuration (WITHOUT jom) and got a close time compilation speed compared with MSVC 2019?

Nope. I do not use MSVC 2019 compiler at all. AFAIK there was an issue with an older MinGW-make not suporting multi-threading. Therefore this discussion and the solution with jom. After my reinstall I did not bother to set up jom again. At day's end some gain is possible by switching to jom, but it was not enough to go through the hassle again.

You seem to use a self-compiled Qt creator version. The output shows strange blanks around the backslashes. Possibly there is your problem with compilation.

ok, the template solution is also working here.
Thanks a lot for your help!

Hi and welcome to devnet,

Quoting myself:
@SGaist said in Qt Creator extremely slow when adding large library INCLUDEPATH:

Can you try with a more recent version ? Current is 4.2

Which may or may not apply to your case.

Hi,

seems that for some reason on your Windows machine QPrinter is very slow.
I suggest to open a BUGREPORT; provide as many information as you can

Hi and welcome to devnet,

I'd recommend bringing that matter to the Qt Creator team through the qt-creator mailing list(don't' forget to subscribed first) or #qt-creator IRC channel.

No problem, that's an information that might be useful to someone else :)

What was taking so long ?

Since you have it working now, please update the thread title prepending [solved] so that other users may know a solution has been found :)

Hi and welcome to devnet,

To discuss such matters, I'd recommend posting on the interest You'll find there Qt's developers/maintainers (This forum is more user oriented)

@zepfan As told earlier the rendering is all done by OpenGL which in turn is handled by the GPU so that wont matter. The Timer is what is affecting the CPU.
QtQuick renderer is capable of handling thousands of items at a time. Please check it here. Also here are some benchmark examples.
Extremetable example loads 100000 items as and when required.
Anyway here are some more link that you may fine useful:
http://doc.qt.io/qt-5/qtquick-performance.html
http://www.sletta.org/apps/blog/show/42708211-looking-at-throughput-in-qt-quick
http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph-renderer.html
Try profiling your example.

@Bremenpl It could be a bug. Please report it Qt BugTracker.