[Testing] : Gas Cost Benchmarks for Diamond events

[AnInsaneJimJam]

The gas benchmarks were run for these scenarios:

• Adding 10 facets, with each facet having 8 selectors.
• Adding 50 facets, with each facet having 8 selectors.
• Adding 100 facets, with each facet having 8 selectors.

Using three event stratergies:
1.) Single Event for whole operation:

event DiamondCut(FacetCut[] _diamondCut);

2.) 1 event per facet( in our case => 10,50,100)

event AddFacet(address indexed facetAddress, bytes4[] functionSelectors);

3.)1 event per function( in our case => 80, 400, 800)

event AddFunction(bytes4 indexed _selector, address indexed _facetAddress);

Result are as follows:

Analysis:

Facet Event is the cheapest and scales with the increase of facets.
Percentages are with comparison with facet event.

Scenario	Single Event	Facet Event	Function Event
10 facets (80 selectors)	2,295,156 ( +0.03 %)	2,294,394	2,372,012 (+3.38%)
50 facets (400 selectors)	11,021,817 (+0.0258%)	11,018,975	11,407,269 (+3.52%)
100 facets (800 selectors)	21,968,096 (+0.0752%)	21,951,595	22,728,211 (+3.54%)

Closes the issue #245

[netlify]

👷 Deploy request for compose-diamonds pending review.

Visit the deploys page to approve it

Name	Link
🔨 Latest commit	8daa5ce

[github-actions]

Coverage Report

Metric	Coverage	Details
Lines	87%	1500/1723 lines
Functions	88%	321/365 functions
Branches	67%	161/239 branches

Last updated: Wed, 10 Dec 2025 08:38:40 GMT for commit 8daa5ce

[github-actions]

Gas Report

No gas usage changes detected between main and events-gas-benchmarks.

All functions maintain the same gas costs. ✅

Last updated: Wed, 10 Dec 2025 08:39:29 GMT for commit 8daa5ce

[mudgen]

Wow! These gas results are surprising!

I would have thought that emitting a single DiamondCut event would cost a lot less gas than the other two approaches, because just emitting an event costs 375 gas. Each indexed argument costs another 375 gas.

It seems to me that the other two approaches would cost a lot more gas because they emit a lot more events that have more indexes. But it is not true so I researched why.

The reason why the Single Event approach in this case costs so much gas is because Solidity has to ABI encode the _diamondCut argument to emit it in an event, and that is very expensive.

The Single Event approach costs more gas because Solidity must perform significantly more ABI-encoding work: it has to encode an array of structs that themselves contain dynamic arrays, which requires far more pointer arithmetic, loops, and memory writes than encoding one facet at a time. Memory expansion contributes somewhat, but it is NOT the dominant factor at the data sizes used — the main cost is simply the amount of encoding work Solidity must do.

[mudgen]

@AnInsaneJimJam Thank you for this very valuable work. Merged into main.

[AnInsaneJimJam]

Yeah, at first I also thought it was a fluke, then I verified for 200,500,1000 facets and percentages rose slowly but steadily. At 1000, it was around 1%. Thank you for providing reason of this behaviour. It is a valuable insight.

[mudgen]

@AnInsaneJimJam Can I see the results for 200, 500, 1000 facets too?

[AnInsaneJimJam]

Yeah, sure . I also included 2000 (bcz why not).

Here is the complete table

Scenario	Single Event	Facet Event	Function Event
10 facets (80 selectors)	2,295,156 (+0.033%)	2,294,394	2,372,012 (+3.38%)
50 facets (400 selectors)	11,021,817 (+0.026%)	11,018,975	11,407,269 (+3.52%)
100 facets (800 selectors)	21,968,096 (+0.075%)	21,951,595	22,728,211 (+3.54%)
200 facets (1600 selectors)	43,987,176 (+0.184%)	43,906,385	45,459,670 (+3.54%)
500 facets (4000 selectors)	111,056,561 (+0.515%)	110,487,358	114,370,653 (+3.51%)
1000 facets (8000 selectors)	226,212,700 (+1.058%)	223,844,317	231,610,962 (+3.47%)
2000 facets (16000 selectors)	469,889,411 (+2.100%)	460,228,223	475,761,486 (+3.37%)

[mudgen]

@AnInsaneJimJam Thank you!