This message was deleted.

fingerprinting is taking the task inputs and creating a hash value of them for later comparison (to determine if anything has changed). The number of inputs (e.g. number of files) and perhaps the size of files are common suspects for slow fingerprinting.

Could you share a screenshot of Performance > Build for that build? Also a screenshot of the timeline would be helpful.

@Eric Haag More context: Our android app is hybrid with react native. When building the app, RN has a task to bundle all the JS files(task name: "bundleReleaseJsAndAssets" as seen in the screenshot) Below are the tasks and respective number of input files app:bundleReleaseJsAndAssets → Number of Input files are around 108396. [lot of js files] module2:packageReleaseAssets → Input files are around 22 [primarily xmls, .kt files] module3:mergeReleaseShaders → Input files are around 57 module4:mergeReleaseShaders → Input files are around 44 module5:mergeReleaseShaders → Input files are around 22 module6:mergeReleaseShaders → Input files are around 562 module7:packageReleaseAssets → Input files are around 32 module8:packageReleaseAssets → Input files are around 38

Thanks. In addition to what @Chris Lee said above, high memory usage and garbage collection times can also contribute towards long fingerprinting times. Based on the screenshot of your performance tab this could also be a culprit.

Hey @Eric Haag Thanks for the previous inputs. Got some more info around this. After checking couple of other gradle scans, I found out that higher fingerprinting input doesn't happen when bundleReleaseJsAndAssets runs before the other merge resource tasks. Basically issue happens only when bundleReleaseJsAndAssets runs parallel with other merge resource tasks. Attached Timeline and Performance screenshots. Also the memory consumption and garbage collection time are in similar range for both scans. @Eric Haag Any input for this would be very much helpful!

It's my pleasure! 😊 Very interesting observation. It still could be caused by resource contention in terms of available threads. Do you know if

bundleReleaseJsAndAssets

is creating multiple threads to perform its work? I am not very familiar with that task.

from above, that task has a huge number of input files:

app:bundleReleaseJsAndAssets → Number of Input files are around 108396. [lot of js files]

Could be various forms of resource contention: • CPU exhaustion; worth viewing a CPU usage timeline to match up with task execution; • Snapshot contention; perhaps there are internal Gradle locks or other areas of contention magnified by large volume of snapshotting. The Gradle Profiler may help here. • while garbage collection isn’t wonderful (50s of GC is not good), that doesn’t fully account for the observed delays. Perhaps review the memory sizing - does the running host have enough physical memory (without swapping) for what appears to be a 10GB heap? Does increasing the heap size (to say 12GB) materially change the performance profile?

@Eric Haag @Chris Lee Thanks for the inputs. Let me check if the task is creating multiple threads. Also let me try increasing the heap size and check the performance!