QtCreator: "Reading Project" very slow
-
Hello,
I have a very large project (my top-level project contains more than 50 subdir-project, some of which are containing multiple sub-projects again).
When changing a QMake file or a QML file (sometimes, not all the time) in one of the sub-projects QtCreator gets blocked for more than 30 seconds while the "Reading Project" stage is running. In older version of QtCreator I was able to work while this was going on, but the latest versions (since 14.0) blocks the whole UI, which is quite annoying, especially when working on QMake files.
Is there an option to make the processing run in the background again, like it was in older versions?(I am running QtCreator 14.0.2)
Regards,
Johan Borkhuis -
This sounds like a regression. Please open a bug report at https://bugreports.qt.io/secure/CreateIssue.jspa?pid=10512
Also try with the latest Qt Creator 15, which is in beta now and might get a quick fix. Qt Creator 14.x series doesn't receives updates anymore.
-
@cristian-adam said in QtCreator: "Reading Project" very slow:
This sounds like a regression. Please open a bug report at https://bugreports.qt.io/secure/CreateIssue.jspa?pid=10512
Also try with the latest Qt Creator 15, which is in beta now and might get a quick fix. Qt Creator 14.x series doesn't receives updates anymore.
I created a ticket for this and installed QtCreator 15. This version still has the same issue.
For both 14 and 15 the rotating wheel in front of the top-level project is also stuck for the period QtCreator is blocked. -
The bugreport is at https://bugreports.qt.io/browse/QTCREATORBUG-31950
-
Any updates on this issue? I just updated my QtCreator to 15.0.0-rc1 (14.0.84) but no changes in behaviour.
-
@Johan-Borkhuis
What updates would you expect here, a forum for users like yourself, over what is shown in the progress of the bug report (which presently shows nothing has been done on it yet)? -
What helps with a bug fixing is:
- An example project that would showcase the issue
- When a regression is happening then pointing out which version was working and the first version that stopped working. This way a developer could do a git bisect to find out the commit that introduced the regression
- Any more technical details about the issue. Traces, etc.
In this case it doesn't help that the project is using QMake, which nowadays is not the most supported build system at Qt.
-
As far as I know it was working in QtCreator 13 (it was with QtCreator 11, as confirmed with a colleague running an older version). I noticed the issue when I upgraded to version 14. In earlier versions you could still edit files and operate the UI while "Reading Project" is active.
Getting an example project is a bit difficult, as our current project is very large, with 60 sub-projects, more than 13000 .cpp files and 600 .pro files (and I expect that that this combination is what is causing the problem).
What option would there be to create some extra data, like traces or debug info from QtCreator?
We are going to move to QMake (as we want to make use of the new Qt6 features), but as you can understand converting a project like this takes a lot of time, as some of the QMake files have a lot of logic inside them. -
Getting logging from Qt Creator would require you to set the environment variable
QT_LOGGING_RULES=qtc*=true
.On Windows you would need a tool like Debug View to see the debug log.
Alternatively Qt Creator has in Tools > Debug Qt Creator > Show Logs....
You could try starting Qt Creator with controlled plugins that get loaded:
$ qtcreator.exe -noload all -load Core -load QmakeProjectManager ...
This way you could find out if there is some plugin that does bad things.
Lastly, use Process Explorer and / or Process Monitor to find out what Qt Creator is doing under the heavy load.
The best option would be to have a profiler on Windows to analyze what's going on. But the usage of ETW is a skill in itself.
-
I am running on Linux (Ubuntu 22.04). When I run QtCreator without the plugins the issue still happens.
When looking withtop
(in thread mode) I see that, as long as the interface is blocked, a lot of extra threads are created. These are all running for a short time and then disappear, to be replaced with another. There are somewhere between 20 and 30 threads active during this period.PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 869716 johan 20 0 9458064 1.3g 149136 S 17.6 5.7 0:30.00 qtcreator 888842 johan 20 0 9458064 1.3g 149136 S 11.8 5.7 0:00.73 Thread (pooled) 888848 johan 20 0 9458064 1.3g 149136 R 11.8 5.7 0:00.72 Thread (pooled) 888853 johan 20 0 9458064 1.3g 149136 S 11.8 5.7 0:00.72 Thread (pooled)