High Overhead in FileFeatureOrigin Caused by Repeated Canonical File Resolution

[lslonina]

🤔 What's the problem you're trying to solve?

In configurations with a significant number of tests, the test discovery time is noticeably long. In our project setup:

• 200+ feature files
• 6000+ containers
• 20000+ tests

Runtime environment: Windows (might behave differently on Linux or other Windows file systems)
Java version: 21

On development machines running Windows, it takes approximately 60–70 seconds to discover features and start test execution. That is true also in case of filtering using tags.

Upon analysis, the slowdown seems to be caused by the FileFeatureOrigin class calling FileSource, which in turn spends most of the time in the file.getCanonicalFile() method:

• [FeatureOrigin.java#L90](

  cucumber-jvm/cucumber-junit-platform-engine/src/main/java/io/cucumber/junit/platform/engine/FeatureOrigin.java

  Line 90 in 731f399

  return FileSource.from(source.getFile(), createFilePosition(node.getLocation()));

  )
• [FileSource.java#L73](https://github.com/junit-team/junit5/blob/7d02a6a2521617ab8502f8614794b7bb0a568603/junit-platform-engine/src/main/java/org/junit/platform/engine/support/descriptor/FileSource.java#L73)

---

✨ What's your proposed solution?

We tried two approaches to reduce the discovery time:

1. Parallel creation of FeatureDescriptions
   By first collecting all features and then creating FeatureDescriptions in parallel, we reduced processing time to ~20 seconds.
   Related code:
   [FeatureResolver.java#L250](

   cucumber-jvm/cucumber-junit-platform-engine/src/main/java/io/cucumber/junit/platform/engine/FeatureResolver.java

   Line 250 in 731f399

   .map(this::createFeatureDescriptor);

   )

2. Custom FileSource implementation with caching
   We implemented a custom FileSource that maintains a static cache (using Guava memoize, but even a HashMap would suffice) to avoid repeated calls to getCanonicalFile().
   This reduced feature discovery time to ~5 seconds, a significant improvement for frequent test runs.

This caching works as long as there's a one-to-many relationship between files and test cases.

---

🔄 Have you considered any alternatives or workarounds?

Providing selected features only when running tests, but can't be used when testing with all scenarios.

---

📚 Any additional context?

This may be relevant to other users with large test suites, especially on Windows, and could potentially be generalized into a configurable optimization in the cucumber-jvm engine.

[mpkorstanje]

Option two makes sense, and there is already a cache present in the FeatureResolver.

Changing the CachingFeatureParser to cache and return a Optional<FeatureWithOrigin> when parsing a feature should solve most of the problems there as a FeatureOrigin would only be created once for every feature.

Would you be interested in creating a pull request?

[mpkorstanje]

Minor problem. For each node, the TestSource is created as:

        @Override
        TestSource nodeSource(Node node) {
            return FileSource.from(source.getFile(), createFilePosition(node.getLocation()));
        }

With no way to bypass getCanonicalFile in the FileSource constructor. I suppose you'd have to propose and send a pull request to the JUnit team to allow for a FileSource from(FileSource file, FilePosition filePosition) function that bypasses the getCanonicalFile operation.

[lslonina]

I've opened an issue with the JUnit team—let's see what feedback we get. Another approach I tested was creating a custom TestSource implementation in Cucumber codebase (essentially a caching copy of FileSource).

However, if this improvement has broader value for the JUnit ecosystem, it makes more sense to implement it directly in JUnit.

[mpkorstanje]

Its a bit more complicated. Implementing a custom TestSource won't work unfortunately. Tooling only checks for a limited number of TestSource implementations, the ones implemented by JUnit. And the pull request to JUnit alone is of-course not enough to fix the performance problems in Cucumber. So we'll have to do both.