Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EVM JSON outputs are generated even when not requested #15615

Closed
DaniPopes opened this issue Dec 5, 2024 · 1 comment · Fixed by #15623
Closed

EVM JSON outputs are generated even when not requested #15615

DaniPopes opened this issue Dec 5, 2024 · 1 comment · Fixed by #15623
Assignees
Labels
bug 🐛 low effort There is not much implementation work to be done. The task is very easy or tiny. medium impact Default level of impact performance 🐎

Comments

@DaniPopes
Copy link
Contributor

DaniPopes commented Dec 5, 2024

Description

Certain evm.*.* output is generated in memory even when not requested through outputSelection. This wastes resources on computing values that are discarded immediately after.

In Foundry, we updated the outputSelection to only include specific fields of evm.bytecode.* as we don't make use of all of them, which was a substantial win in compilation times: foundry-rs/compilers#231. The biggest contributor to this was excluding generatedSources from the JSON, as these can become very large.

The default output selection is now:

["abi","evm.bytecode.object","evm.bytecode.sourceMap","evm.bytecode.linkReferences","evm.deployedBytecode.object","evm.deployedBytecode.sourceMap","evm.deployedBytecode.linkReferences","evm.deployedBytecode.immutableReferences","evm.methodIdentifiers","metadata"]

However, I profiled the compiler and noticed that it was still calling generatedSources.

Here's a profile generated from forge build --use <solc 0.8.29-develop.2024.10.22+commit.9c4995a9.mod.Linux.g++> on superform-xyz/superform-core @ 7b69077 (this is an older build of solc but it should still apply): https://share.firefox.dev/3BaYnLD, using samply

You can see that there is a 4% frame of CompilerStack::generatedSources.

I believe this happens in StandardCompiler. It is generated and passed eagerly to collectEVMObject when any evm.bytecode* output is requested

evmData["bytecode"] = collectEVMObject(
_inputsAndSettings.evmVersion,
compilerStack.object(contractName),
compilerStack.sourceMapping(contractName),
compilerStack.generatedSources(contractName),
false,
[&](std::string const& _element) { return isArtifactRequested(
_inputsAndSettings.outputSelection,
file,
name,
"evm.bytecode." + _element,
wildcardMatchesExperimental
); }
);

but then discarded if the individual evm.bytecode.generatedSources is not requested

if (_artifactRequested("generatedSources"))
output["generatedSources"] = std::move(_generatedSources);

The same applies to other fields, like sourceMap.

Environment

  • Compiler version: 0.8.28, main
  • Target EVM version (as per compiler settings): Paris
  • Framework/IDE (e.g. Truffle or Remix): Foundry
  • EVM execution environment / backend / blockchain client: Foundry
  • Operating system: Linux

Steps to Reproduce

Compile anything with evm.bytecode.object output selection, see above.

@cameel
Copy link
Member

cameel commented Dec 6, 2024

Good find! #15460 solved part of the problem at CompilerStack level but I did not notice that StandardCompiler was also eagerly requesting it rather than doing it only when the output is there. Fixing this should shave off a bit more from the compilation time.

@cameel cameel added performance 🐎 low effort There is not much implementation work to be done. The task is very easy or tiny. medium impact Default level of impact labels Dec 6, 2024
@cameel cameel self-assigned this Dec 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug 🐛 low effort There is not much implementation work to be done. The task is very easy or tiny. medium impact Default level of impact performance 🐎
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants