perf: printing traces is too slow

[0xdapper]

Component

Forge

Have you ensured that all of these are up to date?

• [x] Foundry
• [x] Foundryup

What version of Foundry are you on?

1.5.0

What version of Foundryup are you on?

i use foundry.nix

What command(s) is the bug in?

forge test -vvv

Operating System

Linux

Describe the bug

The forge test -vvv output is too slow. I git bisected through, the first commit with the problem is 824fd99754c6da127605ae5e71ae4c4a78c20e64. Which seems to make a bit of sense too, since it is change in tracing? anyway i can disable sourcify?

I ran it through claude if it is any help:

Yes, there is a significant blocking issue in commit 824fd9975:

  The problem is in crates/evm/traces/src/identifier/external.rs:162:

  let fetched_identities = foundry_common::block_on(
      futures::stream::select_all(fetchers)
          .filter_map(|(address, value)| {
              // ... processing ...
          })
          .collect::<Vec<IdentifiedAddress<'_>>>(),
  );

  The Issue:

  1. Synchronous blocking in trace identification: Every time identify_addresses() is called during test execution, it makes a synchronous blocking
  call (block_on) to fetch contract metadata from external sources (Sourcify and Etherscan).
  2. Called for every trace: When you run forge test -vvv, traces are decoded and addresses are identified, which triggers this blocking call for every
   unique contract address encountered in the traces.
  3. Network I/O in the hot path: The fetchers make HTTP requests to:
    - Sourcify API: https://sourcify.dev/server/v2/contract/{chainId}/{address}
    - Etherscan API: contract source code endpoint
  4. Serial processing per batch: Although it uses select_all to process multiple fetchers concurrently, it still blocks the entire test output/trace
  rendering pipeline waiting for all network requests to complete.

  Performance Impact:

  - Each address lookup involves at least one HTTP request (Sourcify first, then Etherscan)
  - With rate limiting (1 second timeout) and concurrency limits (5 concurrent requests per fetcher)
  - If you have many unique contract addresses in your traces, this can cause significant delays

  The files affected:

  - crates/evm/traces/src/identifier/external.rs:162 - the blocking call
  - crates/forge/src/cmd/test/mod.rs:531 - where the identifier is initialized with .with_external()

  This would explain why forge test -vvv output appears to hang or become very slow when printing traces.

[grandizzy]

@0xdapper you could try set offline = false in foundry.toml, pls lmk if that worked

[0xdapper]

@grandizzy no its still the same

[grandizzy]

@0xdapper sorry, wanted to say offline = true

[0xdapper]

That's better, but doesn't that also turn off forked rpc requests? Doesn't seem like it, incomplete/incorrect description on the help page.

[grandizzy]

if I am not wrong it should turn off only download of solc versions that are not installed locally but maybe better to split these configs. the thing is that sourcify could be slow or rate limiting hence printing traces affected

[0xdapper]

if it only turns off solc download, why does it fix sourcify being slow or rate limited?

[grandizzy]

I meant in addition to tracing it turns off only download of solc versions but doesn't affect forking

[0xdapper]

okay, the offline = true workaround is fine for local, but in CI since it needs to download the compiler as well, I cannot use that and the CI is now basically running for 1h20m or so.