| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
If an artifact map is requested a second time, we need to update the set
of all tags if the artifacts map has changed in the meantime.
This fixes an assertion in the sanity checks.
Change-Id: Iacf8d4376c7a3a356428cc7eb508dbd22e945a8c
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We used to invalidate a script if it accessed the artifacts map and that
map's keys are now different from what they were. However, that logic
was too coarse: All rules that run after the command will add new
artifacts, so such changes will be the norm, at least when the project
is built for the first time. As a result, some artifacts might get
rebuilt unnecessarily on the next qbs invocation.
The reason why we did it that way was that we needed to consider the
case where a script iterated over the elements of an artifacts map, e.g.
using a for..in loop. In such a case, we cannot know which part of the
map the code is interested in and the script needs to be re-run if the
keys change. This is now solved with the help of a QScriptClass, which
informs us if a script enumerates the keys. In all other cases, the
script only accesses well-known tags, so we only have to compare the
respective artifact lists and do not care about other keys getting added
or removed.
Change-Id: I182a50c34ece28f7ff3f7eba7a8f246e9b79b30e
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
|
| |
|
|
| |
Change-Id: Iebe7584bd2978a8f8be093c6b366033076f83e74
|
| |
|
|
|
|
|
|
| |
This fixes a race condition where product.artifacts would contain
outdated information.
Change-Id: I17130a11fbce557314a0157da61c15dae2271189
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
|
| |
|
|
|
|
|
|
| |
... and take the data into account when deciding whether to
re-run rules and commands.
Change-Id: Ib0f733028617eaa91cbf902c5537f30375900646
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
|
| |
|
|
| |
Change-Id: Id4986b2170ac13bf8931656659f6f60432cdbe8d
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These script values were set up from scratch not only for every rule,
but also when creating the dependencies array. As a result, a rule
traversing the dependencies of a product recursively would potentially
create a huge amount of identical script values for modules appearing
more than once in the dependency graph, such as the qbs module. See the
benchmark data below for how the performance degraded with the size of
the project.
Instead, we now re-use these values, which stay valid throughout the
lifetime of the script engine. For prepare scripts, that's the same as
the lifetime of the executor.
As a side effect, this also gives us change tracking for accesses to
product and module properties via the dependencies array. These were
completely unobserved before.
Benchmarker result using qbs as the test project:
========== Performance data for Rule Execution ==========
Old instruction count: 3265471304
New instruction count: 2733833913
Relative change: -17 %
Old peak memory usage: 19023592 Bytes
New peak memory usage: 19871640 Bytes
Relative change: +4 %
Benchmarker result using Qt Creator as the test project:
========== Performance data for Rule Execution ==========
Old instruction count: 318848392341
New instruction count: 75056789023
Relative change: -77 %
Old peak memory usage: 248922136 Bytes
New peak memory usage: 258454408 Bytes
Relative change: +3 %
Change-Id: Id69062eea4dd8f9c7153599610c52bf4ea986464
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
|
|
|
We will need to call it from different places in a follow-up patch.
Change-Id: Ie44c7c55cfdf3859e09526c58a4593bd078e1096
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
|
