feat: Add Stylus Caching Strategy Concept Page #1401
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mahsamoosavi
requested review from
TucksonDev,
anegg0 and
hkalodner
as code owners
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
leeederek
reviewed
Jun 27, 2024
|
|
||
| ### Key features | ||
|
|
||
| The CacheManager plays a crucial role in our caching strategy by keeping a certain set of contracts in-memory rather than retrieving them from disk. This significantly reduces the activation time for frequently accessed contracts. The CacheManager contract is an on-chain contract that accepts bids for inserting contract code into the cache. It then calls a precompile that loads or unloads the contracts in the ArbOS cache, which follows the on-chain cache but operates locally in the client, and marks the contract as in or out of the cache in the ArbOS state. |
There was a problem hiding this comment.
Is it true that the cache manager reduces only activation time? Wouldn't subsequent calls (after activation) be cheaper in gas too?
tsahee
reviewed
Jun 28, 2024
| sidebar_position: 3 | ||
| --- | ||
|
|
||
| Stylus is designed for fast computation, but it faces significant performance issues due to the slow activation process when entering a contract. This slow [activation](https://docs.arbitrum.io/stylus/stylus-gentle-introduction#activation) takes up substantial resources and time. These repeated activations lead to inefficiencies and hinder the overall performance of the system. To address this problem, we have implemented a caching strategy. The cache serves as a bypass, storing frequently accessed contracts in-memory. This approach allows for avoiding repeated activations, thereby saving resources and time while significantly improving the speed and efficiency of contract execution. |
There was a problem hiding this comment.
Activation is different. You only need to activate a program once and then it stays "active" for a year or until stylus version changes. It's unrelated to caching.
Here we're talking about something else - in some places it's called "initialization" in this document, which is a good name for it.
Most places where you describe "activation" in this doc should be changed to "initialization"
|
|
||
| The CacheManager plays a crucial role in our caching strategy by keeping a certain set of contracts in-memory rather than retrieving them from disk. This significantly reduces the activation time for frequently accessed contracts. The CacheManager contract is an on-chain contract that accepts bids for inserting contract code into the cache. It then calls a precompile that loads or unloads the contracts in the ArbOS cache, which follows the on-chain cache but operates locally in the client, and marks the contract as in or out of the cache in the ArbOS state. | ||
|
|
||
| The cache operates through an auction system where dapp developers submit bids to insert their contracts into the cache. If the cache is at capacity, lower bids are evicted to make space for higher bids. The cache maintains a min heap of bids for codeHashes, with bids encoded as `bid << 64 + index`, where `index` represents the position in the list of all bids. When an insertion exceeds the cache's maximum size, items are popped off the min heap and deleted until there is enough space to insert the new item. Zero bids are the first to be popped off based on their index, leading to random evictions due to the non-meaningful ordering of entries. Otherwise, the smallest bid is evicted first. |
There was a problem hiding this comment.
I don't think we need to detail zero-bids specifically. Saying that contracts with equal bids will be popped in a random order is better.
|
|
||
| ### Cache access and costs | ||
|
|
||
| During activation, we compute initialization costs for both non-cached and cached initialization of the contract. These costs take into account factors such as the number of functions, types, code size, data length, and memory usage. It's important to note that ccessing an uncached contract does not automatically add it to the CacheManager's cache. Only explicit calls to the CacheManager contract will add a contract to the cache. If a contract is removed from the cache, calling the contract becomes more expensive unless it is re-added. |
There was a problem hiding this comment.
Here usage of "activation" is correct, and "initialization" is used to describe the thing that the cache reduces the cost of.
anegg0
approved these changes
Jul 9, 2024
anegg0
approved these changes
Jul 10, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.