-
Notifications
You must be signed in to change notification settings - Fork 324
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Add Stylus Caching Strategy Concept Page #1401
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
||
### 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it true that the cache manager reduces only activation time? Wouldn't subsequent calls (after activation) be cheaper in gas too?
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here usage of "activation" is correct, and "initialization" is used to describe the thing that the cache reduces the cost of.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great to me, I did minor edits, feel free to let me know if you object to any of them.
No description provided.