# Gas Saving Tutorial 41: In-lining Single Use Modifiers For Gas Saving

{% hint style="info" %}
[**Book an audit with Zokyo**](https://www.zokyo.io/)
{% endhint %}

**Introduction:** Modifiers in Solidity are powerful tools that provide a way to add pre-conditions to function executions. However, while they can make code more readable and modular, their use isn't always the most gas-efficient approach, especially when the modifier is used only once. In such scenarios, directly incorporating the modifier's logic into the function can save on gas costs. In this tutorial, we will discuss the concept of inlining modifiers and how it can help optimize gas consumption.

***

**Concept:** When a modifier is invoked, there's an associated overhead due to the added layer of execution. In cases where a modifier is used multiple times throughout a contract, this overhead can be justified by the enhanced readability and code reusability. However, when a modifier is used only once, the gas overhead becomes unnecessary, and inlining the modifier's logic directly into the function can result in gas savings.

***

**Underlying Problem:**

1. **Extra Overhead:** Using a modifier introduces additional gas costs related to its execution.
2. **Redundancy:** A modifier used only once doesn't capitalize on its primary advantage of code reusability.

***

**Example:**

**With a Single-use Modifier:**

```solidity
solidityCopy codemodifier onlyWhitelistedProfileCreator() {
    require(isWhitelistedProfileCreator(msg.sender), "Not a whitelisted profile creator");
    _;
}

function createProfile(DataTypes.CreateProfileData calldata vars) external onlyWhitelistedProfileCreator {
    // Function logic
}
```

**Inlining the Modifier:**

```solidity
solidityCopy codefunction createProfile(DataTypes.CreateProfileData calldata vars) external {
    require(isWhitelistedProfileCreator(msg.sender), "Not a whitelisted profile creator");
    // Function logic
}
```

***

**Recommendation:**

1. Review your contracts and identify any modifiers that are used only once.
2. For such single-use modifiers, directly incorporate the modifier's logic into the respective function.
3. Ensure that the logic's placement within the function doesn't affect the function's behavior or security.
4. Test the refactored code to guarantee consistent behavior.
5. Always prioritize gas optimization by assessing the true need for a modifier based on its frequency of use.

***

**Conclusion:** While modifiers are undeniably useful for enhancing code readability and modularization, they're not always the most gas-efficient option. Especially in cases of single-use modifiers, inlining them can save on gas, ensuring a more economical execution. By regularly evaluating the need for modifiers and balancing between readability and gas costs, developers can create efficient and cost-effective smart contracts.

<br>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://zokyo-auditing-tutorials.gitbook.io/zokyo-gas-savings/tutorials/gas-saving-tutorial-41-in-lining-single-use-modifiers-for-gas-saving.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.