Draft
Conversation
RandomByte
force-pushed
the
feat/incremental-build-4
branch
3 times, most recently
from
5224cd2 to
4904c84
Compare
RandomByte
force-pushed
the
feat/incremental-build-4
branch
from
950fc6d to
41eed91
Compare
maxreichmann
force-pushed
the
feat/incremental-build-4
branch
from
bb39565 to
2a21507
Compare
RandomByte
force-pushed
the
feat/incremental-build-4
branch
3 times, most recently
from
6233816 to
f858659
Compare
RandomByte
force-pushed
the
feat/incremental-build-4
branch
from
71db1d0 to
a2c371f
Compare
RandomByte
force-pushed
the
feat/incremental-build-4
branch
from
7364b4b to
cf43f0c
Compare
maxreichmann
force-pushed
the
feat/incremental-build-4
branch
2 times, most recently
from
252b966 to
874a943
Compare
RandomByte
commented
Feb 18, 2026
maxreichmann
force-pushed
the
feat/incremental-build-4
branch
5 times, most recently
from
df275e5 to
0345502
Compare
RandomByte
commented
Mar 5, 2026
RandomByte
force-pushed
the
feat/incremental-build-4
branch
from
9fc2509 to
20ba653
Compare
maxreichmann
force-pushed
the
feat/incremental-build-4
branch
from
20ba653 to
9fc2509
Compare
RandomByte
force-pushed
the
feat/incremental-build-4
branch
from
9fc2509 to
940376d
Compare
RandomByte
force-pushed
the
feat/incremental-build-4
branch
from
9197670 to
44d1107
Compare
maxreichmann
force-pushed
the
feat/incremental-build-4
branch
from
44d1107 to
d7c402c
Compare
Member
|
Rebased onto origin/main |
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
* Add test for "ui5 --version" * Add test for "ui5 build" (currently testing a TS application) Currently, those tests are not included in any CI pipeline and also need a manual "npm install" (no node_modules included yet).
+ Include "npm install" in test runtime
+ Refactor test environment for better reuse + Extend typescript test to cover Incremental Build
+ Add "application.a" (Javascript project fixture)
…ently FAILING) + Refactor "ui5-tooling-modules" test
…gistry.flush Split upsertResources into two phases: concurrent I/O resolution via Promise.all (getIntegrity, getSize, matchResourceMetadataStrict) followed by serial tree mutation. This avoids sequential file reads when processing many resources. Pre-resolve getIntegrity and getSize for all pending resources concurrently via Promise.all before the serial tree-mutation loop. This avoids redundant sequential I/O across the triple-nested directory x tree x resource loop.
Restructure updateIndices() into 3 phases: collect all unique paths across request sets, batch-fetch in parallel via Promise.all, then process synchronously from cache. Also parallelize refreshIndices() node processing since SharedHashTree operations schedule atomically into the TreeRegistry.
Add unchangedNodes Set in TreeRegistry.flush() to track resource nodes already confirmed unchanged via matchResourceMetadataStrict. Subsequent trees sharing the same node skip the full comparison and only check tags, eliminating N-1 async calls per shared resource across N trees.
Overlap stage cache I/O by prefetching metadata for the next task while the current task is executing. This reduces idle time between sequential task executions in warm-cache builds.
Add structured timing and counters to identify I/O hotspots in the build cache validation flow. Instrumentation covers refreshIndices, updateIndices, flushTreeChanges, TreeRegistry.flush phases, and matchResourceMetadataStrict. All gated behind @ui5/logger perf level or UI5_CACHE_PERF env var.
Add perf-level timing to the build orchestration layer to identify the ~6.5s gap observed in warm-cache builds between source index initialization and per-project cache validation. Instruments: - getRequiredProjectContexts (total + per-project context creation) - prepareProjectBuildAndValidateCache (getDependenciesReader vs cache) - #flushPendingChanges (source index vs dependency index updates) - ProjectBuilder.#build per-project timing
Defer source index initialization from ProjectBuildCache.create() to a separate initSourceIndex() method, allowing BuildContext to initialize all project source indices concurrently via Promise.all instead of sequentially in the dependency discovery loop.
During dependency index updates, the cache proxy reader eagerly called cacache.get.info() for every byPath() request, even though the callers (hash tree upserts) only need resource metadata. With 2550+ parallel calls, this created severe filesystem I/O contention (~2.2s). Defer the cache path resolution to first content access using a lazy singleton promise pattern. Also replace O(n) Array.includes() with O(1) object property lookup and fix the size/byteSize parameter mismatch. sap.ui.layout updateDependencyIndices: 2466ms -> 59ms Total warm-cache build: 2.85s -> 315ms
RandomByte
force-pushed
the
feat/incremental-build-4
branch
from
ec2aa62 to
7dd19c9
Compare
…ing cache writes Track integrity hashes from restored stage metadata in a Set and skip cacache.get.info() calls for resources already known to be in CAS. Reduces cache write time from ~1,400ms to ~100ms for stale-cache builds by eliminating ~15,000 redundant CAS existence checks.
… import On first CLI invocation, #importStages treated all restored stage resources as "changed" because #currentStageSignatures was empty. This caused ~3000+ resource paths to be propagated to dependents, triggering expensive updateDependencyIndices calls (~108ms total). The imported stages represent the already-cached state, not actual changes. Skip writtenResourcePaths accumulation when this is the initial import (empty #currentStageSignatures), since dependents' dependency indices were restored from the same persistent cache.
…pagated When restoring from cache, dependency indices are already populated via BuildTaskCache.fromCache. If no dependency changes were propagated from upstream projects, the cached indices are already correct and _refreshDependencyIndices can be skipped entirely. This avoids fetching ~2738 resources per dependent just to confirm nothing changed, saving ~130ms on warm-cache builds.
…esult, and source freeze Add perf-level timing to previously unlogged operations that dominate stale-cache build time: - allTasksCompleted: overall timing + sub-timings for revalidateSourceIndex and freezeUntransformedSources - revalidateSourceIndex: byGlob timing for source file re-read - freezeUntransformedSources: byPath reads and writeStageResources - recordTaskResult: overall timing + delta merge and recordRequests Investigation of a stale-cache sap.m build (1 file changed) showed allTasksCompleted taking 11.3s of a 12s build, with freezeUntransformedSources accounting for 10.2s due to per-resource CAS existence checks.
In #freezeUntransformedSources, retain the previous build's frozen source resourceMetadata and reuse entries for untransformed paths that haven't changed, avoiding byPath reads and metadata collection for ~12K resources. For sap.m stale-cache builds (1 file changed), this reduces #freezeUntransformedSources from ~1,212ms to ~31ms.
RandomByte
force-pushed
the
feat/incremental-build-4
branch
from
7dd19c9 to
4928143
Compare
Cover the RESTORING_DEPENDENCY_INDICES state handling in prepareProjectBuildAndValidateCache, verifying that: - _refreshDependencyIndices is skipped when no dependency changes were propagated (warm cache scenario) - dependencyResourcesChanged() moves state to REQUIRES_UPDATE, routing changes through #flushPendingChanges instead - State correctly transitions from RESTORING_DEPENDENCY_INDICES to FRESH after the first prepareProjectBuildAndValidateCache call - Subsequent dependency changes use the REQUIRES_UPDATE path
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Implementation of RFC 0017 Incremental Build
This PR supersedes previous PoC: #1238
JIRA: CPOUI5FOUNDATION-1174