Open c4-submissions opened 1 year ago
4 r 4 nc
UBS-01G: Significant Optimization of Overall Transaction Parsing r
LCH-01G: Inefficient Evaluation of Modulo nc
LCH-02G: Inefficient Evaluation of Multiplication nc
ALS-01G: Inefficient Mapping Lookups r
DDN-01G: Inefficient Memory Expansion r
DDN-02G: Inefficient Mapping Lookups d
LMP-01G: Sub-Optimal Fork of Solady r
MEL-01G: Inefficient Evaluation of Modulo d
MEL-02G: Inefficient Evaluation of Division d
ESR-01G: Inefficient Evaluation of Ternary Operator nc
MXO-01G: Inefficient Mapping Lookups d
LER-01G: Inefficient Mapping Lookups d
LWB-01G: Inefficient Mapping Lookups d
GSE-01G: Inefficient Iterator Increment Statement nc
BZS-01G: Inefficient Iterator Increment Statement d
141345 marked the issue as sufficient quality report
GalloDaSballo marked the issue as grade-b
Hey @141345, I would be keen to know why the following optimizations are marked as "d":
For example, DDN-02G refers to the following lookups:
Diamond::_addOneFunction
: Will optimize at best 2 lookups, at worse 1 lookup Diamond::_removeOneFunction
: Will optimize at best 3 lookups, at worse 1 lookupPlease keep in mind that a mapping
entry lookup performs a keccak256
instruction under the hood (as well as potential abi.encode
etc. methods) to construct the "key" (i.e. storage offset) to access an entry. I am more than happy to produce supplemental test cases showcasing the gas savings of each exhibit.
Additionally, BZS-01G
is marked as d
while GSE-01G
is marked as nc
which does not make sense as they relate to the exact same type of optimization.
I have checked adding further refactorings to this report score and don't believe it would qualify for A at this time
I also agree with the Presorter Heuristic that a specific type of optimization (lookup) should be awarded only once
I recommend listing the instances in sequence instead of sending them file by file
See the markdown file with the details of this report here.