Skip to content

Conversation

@DaniPopes
Copy link
Member

Closes #8898.

Continuation of #11769 + #11842. See these PRs for more details.

- Unified CorpusEntry constructors with internal _new method taking
  Option<PathBuf> to eliminate code duplication between new and
  from_tx_seq.

- Extracted common helper methods in WorkerCorpus:
  - can_replay_tx: static helper to check if tx can be replayed,
    replacing 2 duplicate closures.
  - file_extension: returns appropriate file extension based on gzip
    config, replacing 3 duplicated patterns.

- Simplified directory initialization using functional map pattern
  instead of nested if-let, and removed unnecessary is_dir checks
  before create_dir_all calls.

- Improved parse_corpus_filename by replacing rsplitn + collect with
  rsplit_once for better efficiency and added proper error message for
  invalid format.

- Removed unused uuid field from CorpusDirEntry struct, fixing clippy
  dead_code warning.

- Reordered early returns in export method to check master worker
  first for more logical flow.
counterexample: (calldata, call),
breakpoints,
}))
rayon::current_num_threads() as u32
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's unclear to me if this would be 0 if threads config is omitted

if self.threads.is_some() {
self.force_init_thread_pool()?;
}

If it's all available threads, I'm wondering if it may exacerbate issues like this #12397. Would it make sense to take memory into account and lower the thread count accordingly or default to a lower num?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes it would, the default is number of threads. i don't think this would have memory issues more than the current implementation, but it does exacerbate storage instead since we never prune anything

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: No status

Development

Successfully merging this pull request may close these issues.

forge test doesn't utilize all available threads for fuzzing/invariants

4 participants