Skip to content

Conversation

@mokarchi
Copy link

@mokarchi mokarchi commented Oct 24, 2025

How It Works

Fix this
When you call new ArchLoader().LoadAssemblies(...).Build(), ArchUnitNET automatically:

  1. Creates a cache key based on the modules being loaded and any namespace filters applied
  2. Checks the cache for a previously loaded Architecture instance matching this key
  3. Returns the cached instance if found, or loads and caches a new instance if not

This means that loading the same assemblies multiple times (even with different ArchLoader instances) will reuse the cached Architecture object, providing dramatic performance improvements.

Usage Examples

Basic usage (automatic caching with file-based invalidation):

var arch = new ArchLoader()
    .LoadAssemblies(assembly)
    .Build(); // Automatically cached with invalidation

Custom cache key for test isolation:

var arch = new ArchLoader()
    .WithUserCacheKey("test-run-1")
    .LoadAssemblies(assembly)
    .Build();

Disable caching for specific scenarios:

var arch = new ArchLoader()
    .WithoutCaching()
    .LoadAssemblies(assembly)
    .Build();

Advanced configuration (config is cloned internally):

var config = new ArchLoaderCacheConfig
{
    CachingEnabled = true,
    UseFileBasedInvalidation = true, // Check file changes
    UserCacheKey = "integration-tests",
    IncludeVersionInCacheKey = true // Invalidate on version change
};

var arch = new ArchLoader()
    .WithCacheConfig(config)
    .LoadAssemblies(assembly)
    .Build();

// Safe: modifying config after passing it won't affect the ArchLoader
config.UserCacheKey = "different-key";

alexanderlinne and others added 2 commits October 25, 2025 08:37
Signed-off-by: Alexander Linne <[email protected]>
Signed-off-by: mokarchi <[email protected]>
Introduced a new caching system via `ArchitectureCacheManager` to improve performance and efficiency of `ArchLoader` builds. The caching mechanism supports file-based invalidation, user-defined cache keys, and version-based cache invalidation.

Key changes:
- Added `ArchitectureCacheManager` for centralized caching.
- Introduced `ArchLoaderCacheConfig` for configurable caching options.
- Added `AssemblyMetadata` to track assembly file changes.
- Enhanced `ArchBuilder` with a new `Build` method supporting caching.
- Improved `ArchLoader` with fluent API methods for caching configuration.
- Added extensive unit tests to validate caching behavior and performance.

Refactored code to integrate caching seamlessly while maintaining backward compatibility. Improved performance for repeated builds of the same assemblies.

Signed-off-by: mokarchi <[email protected]>
@mokarchi
Copy link
Author

@alexanderlinne Could you review this, please?

@EngRajabi
Copy link

We’re also experiencing very slow performance with large projects — when there are many files, it becomes extremely slow and can take up to 15 minutes to complete. Hopefully, this merge will address the issue.

@alexanderlinne
Copy link
Collaborator

alexanderlinne commented Nov 28, 2025

Hi @mokarchi,

what you've implemented here, as far as I see, is in principle already covered by ArchitectureCache. So if you load the exact same architecture with exact same assemblies twice within the same test run, the Architecture should already be reused. I don't see what justifies second implementation of the same functionality here. Could you explain what the exact additional functionality provided here is?

I'd see the addition of WithoutCaching as a solution for #399 and we could improve the ArchitectureCacheKey if there were cases in which it is not unique. But this could as well be implemented with the existing cache implementation.
Performance-wise I'd expect the biggest improvement could probably be achieved by moving some work that is currently done when calling LoadAssemblies into the build method after the existing architecture cache check.

@alexanderlinne alexanderlinne added waitforfeedback triage/needs-information Indicates an issue needs more information in order to work on it. labels Nov 28, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

triage/needs-information Indicates an issue needs more information in order to work on it. waitforfeedback

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants