Clarify and Potentially Refine --optimize-runs Parameter

The --optimize-runs parameter controls the crucial trade-off between deployment cost and execution cost . However, a common misconception is that it controls the number of optimization iterations, rather than the expected frequency of execution . This can lead to suboptimal choices and a lack of understanding among developers. The optimizer documentation notes that it is "undergoing heavy development" , implying its behavior might evolve.

Proposed Solution

Improve Documentation: Enhance the documentation for --optimize-runs to clearly and prominently explain its purpose as a trade-off metric, explicitly debunking the misconception that it controls the number of optimizer passes. Provide concrete examples or heuristics for typical use cases (e.g., "For frequently called library functions, use a higher value").

Review Default Value: Assess whether the default value (currently 200) is still optimal for the majority of use cases on modern networks (like Ethereum and L2s where gas costs differ) or if a dynamic or project-specific recommendation could be made.

Consider New Heuristics: If feasible, research and propose a more advanced heuristic for the optimizer runs that could be more intelligent, perhaps estimating a "total cost over the contract's lifetime" based on the code's structure or average transaction count.

Impact

Medium: Empowers developers to make more informed decisions about their contract's gas economics, leading to more efficient and cost-effective dApps.

Medium: Reduces confusion and support requests related to this important compiler flag.

Labels
documentation, optimizer, gas, enhancement