Performance: Repeated ServiceLoader scanning without caching

Problem

ServiceLoader instances are being loaded and scanned repeatedly during WorkflowApplication.build() and other initialization paths without caching the results. ServiceLoader scanning is expensive because it:

Iterates through all entries on the classpath
Instantiates service provider classes
Maintains internal state that's recreated each scan

This becomes a bottleneck when:

Multiple WorkflowApplication instances are created
Services are looked up frequently during workflow execution
Large numbers of plugins/implementations exist on the classpath

Current Issues

WorkflowApplication.java (lines 472, 482)

ServiceLoader.load(ExpressionFactory.class).forEach(exprFactories::add);
// ... later ...
ServiceLoader.load(EventPublisher.class).forEach(e -> eventPublishers.add(e));

Called during every build() invocation.

RunTaskExecutor.java (line 36)

private static final ServiceLoader<RunnableTaskBuilder> runnables =
    ServiceLoader.load(RunnableTaskBuilder.class);

Then rescanned via runnables.stream() with .sorted() on every task execution.

EmitExecutor.java (line 48)

private static final Collection<EmittedEventDecorator> emittedDecorators =
    ServiceLoader.load(EmittedEventDecorator.class).stream()
        .map(ServiceLoader.Provider::get)
        .sorted()
        .toList();

RunScriptExecutorBuilder.java (line 57)

ServiceLoader lookup happens per task without caching results by language.

DefaultTaskExecutorFactory.java (line 50)

private Collection<CallableTaskBuilder> callTasks =
    ServiceLoader.load(CallableTaskBuilder.class)
        .stream()
        .map(Provider::get)
        .sorted()
        .toList();

Good example of caching (at initialization), but other locations don't follow this pattern.

Impact

Startup time: Multiple milliseconds added per WorkflowApplication creation
Throughput: Each task execution incurs sorting/filtering overhead
Resource usage: Unnecessary object allocations and classpath scanning

Suggested Fix

Cache ServiceLoader results at WorkflowApplication level
Make cached providers available to task executors
Index results by type/language for O(1) lookups instead of O(n) filtering
Document caching pattern for future service implementations

Example Solution (Conceptual)

// In WorkflowApplication
private final Map<Class<?>, Collection<?>> serviceLoaderCache = new ConcurrentHashMap<>();

<T> Collection<T> loadServices(Class<T> serviceClass) {
    return (Collection<T>) serviceLoaderCache.computeIfAbsent(
        serviceClass,
        k -> ServiceLoader.load(serviceClass).stream()
            .map(ServiceLoader.Provider::get)
            .sorted()
            .toList()
    );
}

Then pass this through to executors that need service lookups.

perf: Cache EmittedEventDecorator lookups in EmitExecutor (open-workf…

There should not be multiple WorkflowApplication objects within the same JVM
If you follow that policy (which must be followed), not caching the service loader in WorkflowApplication should not be an issue (so there is no performance improvement in caching services that are only processed during WorkflowApplicaiton.build(), but there is an impact in memory because those collection will remain associated to the application, so, on summary, do NOT create several WorkflowApplication object in your JVM and do not create cached collection for service loaders used in Workflowapplication)
For other usages of uncached service loaders outside workflow application (which I think are only Run and Emit cases) please feel free to open PR.

I did further analysis,
WorkflowApplication, as already discussed, should not be cached (one of the only valid reasons to load different Workflowapplication withint the same JVM is actually to rescan application service loaders)
EmitExecutor is already "cached", so it only loaded once, no cache necessary (yes this actually creates an assimetry with WorkflwApplication ones, but it can be justified by the nature of the decorator)
RunScriptExecutor, RunTaskExecutor and HttpExecutor ones are only loaded once per workflow definition (not per execution, thats a critical point) containing a script, but they are good candidates for cachig (caching makes a lot of sense)
Im opening a PR for those three.

Navigation Menu

Repository navigation

Performance: Repeated ServiceLoader scanning without caching #1611

Problem

Current Issues

WorkflowApplication.java (lines 472, 482)

RunTaskExecutor.java (line 36)

EmitExecutor.java (line 48)

RunScriptExecutorBuilder.java (line 57)

DefaultTaskExecutorFactory.java (line 50)

Impact

Suggested Fix

Example Solution (Conceptual)

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Performance: Repeated ServiceLoader scanning without caching #1611

Description

Problem

Current Issues

WorkflowApplication.java (lines 472, 482)

RunTaskExecutor.java (line 36)

EmitExecutor.java (line 48)

RunScriptExecutorBuilder.java (line 57)

DefaultTaskExecutorFactory.java (line 50)

Impact

Suggested Fix

Example Solution (Conceptual)

Activity

fjtirado commented on Aug 11, 2026

fjtirado commented on Aug 11, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions