runtime/Optimize accounts loading (one pass) by HaoranYi · Pull Request #1157 · anza-xyz/agave

HaoranYi · 2024-05-02T22:29:50Z

Problem

During transaction execution, we load accounts twice - first during filtering program accounts, and second for loading the actual accounts before execution. And by default, loading program accounts will insert the loaded program accounts into read cache, which pollutes read cache unnecessarily. This is inefficient and can be optimized.

This is an alternative idea for #1056 and #1180

Summary of Changes

Add a new API for account-db load_with(), which takes a callback to indicate whether to insert the loaded account into read_cache.
Update program account loads and transaction accounts loads to use the new API to do finer control on whether to insert the account into read_cache after loading.
Implement one pass for loading the account.
Remove the filtering pass completely.
Reorder loading account before program cache replenish.

Performance Comparision

account load time (top-left); prog_cache time (top-right), replay time (bottom)
blue (this PR), red (master)

Account loading time increased, program cache time decreased. The decrease of program cache time is more than the increase of accounts loading time. Total replay time decreased.

Fixes #

codecov-commenter · 2024-05-03T19:24:48Z

Codecov Report

Attention: Patch coverage is 99.57627% with 2 lines in your changes are missing coverage. Please review.

Project coverage is 82.7%. Comparing base (92b093d) to head (e4b9e9c).

Additional details and impacted files

@@            Coverage Diff            @@
##           master    #1157     +/-   ##
=========================================
- Coverage    82.7%    82.7%   -0.1%     
=========================================
  Files         876      876             
  Lines      371130   371181     +51     
=========================================
+ Hits       307273   307314     +41     
- Misses      63857    63867     +10

HaoranYi · 2024-05-06T18:01:10Z

svm/src/account_loader.rs

-                    // programs in top-level instructions and not passed as instruction accounts.
-                    let program_account = account_shared_data_from_program(&program);
-                    (program.account_size, program_account, 0)
                } else {


This optimization, which set program account data to empty, is not applicable
any more because we no longer prime program cache before loading the accounts.

There is also a change on the reported execution errors when a transaction is
called for uninitialized or buffer program accounts. The original code will
throw "InvalidAccountData" error, while this PR will throw
"InvalidProgramForExecution" error. The reason is that original code will mark
the program account executable and failed on a later check when execute the
program. This PR will fail on executable check in this function early on.

Fortunately, this change won't affect consensus because program errors are not
part of the consensus.

Lichtso · 2024-05-13T15:48:03Z

I think the massive increase in account load time can be explained by the fact that we are still loading missing program accounts twice. And now the second read is not in the read cache combined with the fact that program accounts are big cause this to be a lot. However, this would only make sense if it is roughly proportional to the program cache misses. Can you add program cache misses to the account load time plot so we can see if it correlates?

HaoranYi · 2024-05-13T16:12:53Z

program cache misses seem to be similar.

Lichtso · 2024-05-13T16:19:59Z

Hm, problem is that the account load time has a very high base line while the program cache misses have a very low base line. So it can't explain it completely and there must be some other effect going on.

HaoranYi · 2024-05-13T16:33:38Z

In master, we are doing a filtering pass on the accounts before actually loading the account. The filtering pass could be "prefetch" the accounts into memory by os, which benefit the loading. The filtering timing is counted into prog_cache stats in master, but no longer exists for this PR. That's why we see a big decrease in prog_cache time.

In this PR, we are not filtering and loading the accounts directly. We don't have the benefit of prefetching. Probably, that's why aaccount load_us is much higher than the base line.

Lichtso · 2024-05-13T16:42:42Z

So, in other words it is the same time spent, just measured / counted in a different category. Makes sense.

accounts-db/src/accounts_db.rs

accounts-db/src/read_only_accounts_cache.rs

Lichtso · 2024-05-14T12:05:12Z

svm/src/account_loader.rs

-                            if message.is_writable(i) {
+                        .load_account_with(key, |account| {
+                            // only cache account that is not writable and not having program owners.
+                            !is_account_writable && !program_owners.contains(account.owner())


Can you test how much performance changes if you remove the !is_account_writable &&? I suspect it would be barely measurable, as program management instructions are quite rare. Also, the writeability should not determine if it goes into the read cache or not.

In the above graph, red, no writable check, shows better load time.
total replay time didn't change much.

Can you run one more test with .load_account_with(key, |account| false), effectively disabling the read caching altogether?

sure. will do.

So total replay just gets a little more variance with the read caching enabled.
But you did not disable it in both places where load_account_with() is used and missing program loading still does the read cached load right?

Both places are disabled.
The missing program loading already have the callback to return false.

So where else is the read cache populated then? The blue read cache hits graph is not zero.

There are many other places that load accounts and populate read cache besides transaction processor.

programdata account

program owner account

sysvar account

vote account

feature account

buildin account

nounce account

fee account

withdraw/deposit

The following commit lists several places that we populate read cache.
cc2bacc

Some of them should be optimized to skip populating read cache obviously. For example, vote account, and sysvar accounts and fee paying accounts. And some may need more context, i.e. nounce accounts?

I think this change is out of scope of this PR. Probably, we need another project to review all the places that we load accounts and decide whether it is valuable to store the accounts into the cache.

It is unfortunate that we choose the default to put the account into read cache when loading them. Probably, we should have defaulted to not putting account into read cache.

#1405 will avoid inserting the accounts into read ache for items 8/9.

svm/src/account_loader.rs

accounts-db/src/accounts_db.rs

svm/src/account_loader.rs

svm/src/program_loader.rs

HaoranYi · 2024-05-17T12:19:00Z

blue: with read_cache completely disabled.
red: with read_cache enabled.

load time with cache (red) is a better. But the replay time without cache (blue) seems to be a little better.

alessandrod · 2024-06-17T04:45:27Z

@HaoranYi ping? are you going to attempt #1408 (comment)?

HaoranYi · 2024-06-17T14:33:10Z

svm/src/account_loader.rs

-                            if message.is_writable(i) {
+                        .load_account_with(key, |_account| {
+                            // cache the account in read-only cache
+                            true


@alessandrod

#1408 (comment) is addressed here.

HaoranYi · 2024-06-17T14:33:51Z

@HaoranYi ping? are you going to attempt #1408 (comment)?

Yes, this is addressed.

HaoranYi · 2024-06-17T15:42:26Z

svm/src/account_loader.rs

        assert_eq!(account.lamports(), 0);
    }
+
+    #[test]


The following tests are adapted from corresponding tests in transaction_processor.rs, and moved here, since we get rid of fn filter_program_accounts() from transaction_processor.rs.

HaoranYi · 2024-06-17T17:17:33Z

Rebase the PR on top of master to pick up recent svm changes.

alessandrod · 2024-06-20T04:45:23Z

I'm profiling this now, ideally I'd like to get it in before we branch 2.0

HaoranYi · 2024-06-20T13:50:58Z

rebase to master to pick up audit fixes.

HaoranYi · 2024-06-21T14:20:32Z

rebase again.

HaoranYi · 2024-07-09T14:27:48Z

Rebase on master.

apfitzge · 2025-08-04T15:36:59Z

@HaoranYi are there still plans for this PR?

I noticed the load_account_with callback was never actually something other than just true or false, and changed it here: #7294.

Lichtso · 2025-08-04T17:29:53Z

#6036 is what we are currently aiming for

Lichtso · 2025-12-15T14:16:32Z

Closing as #6036 has landed.

HaoranYi force-pushed the runtime/owner_check2 branch 2 times, most recently from 21b2fd7 to 985c590 Compare May 3, 2024 01:01

HaoranYi changed the title ~~runtime/owner check2~~ runtime/Optimize program and transaction accounts load 2 May 3, 2024

HaoranYi changed the title ~~runtime/Optimize program and transaction accounts load 2~~ runtime/Optimize program and transaction accounts load (one pass) May 3, 2024

HaoranYi force-pushed the runtime/owner_check2 branch from 62a6488 to e15a1a9 Compare May 3, 2024 19:47

HaoranYi changed the title ~~runtime/Optimize program and transaction accounts load (one pass)~~ runtime/Optimize accounts loading (one pass) May 3, 2024

HaoranYi commented May 6, 2024

View reviewed changes

HaoranYi force-pushed the runtime/owner_check2 branch 2 times, most recently from 7658cc1 to e0d2ab3 Compare May 10, 2024 14:04

HaoranYi marked this pull request as ready for review May 13, 2024 14:38

HaoranYi requested review from Lichtso, alessandrod, brooksprumo, jeffwashington and pgarg66 May 13, 2024 14:38

brooksprumo reviewed May 13, 2024

View reviewed changes

accounts-db/src/accounts_db.rs Outdated Show resolved Hide resolved

accounts-db/src/read_only_accounts_cache.rs Show resolved Hide resolved

brooksprumo self-requested a review May 13, 2024 17:25

Lichtso reviewed May 14, 2024

View reviewed changes

HaoranYi mentioned this pull request May 14, 2024

Add load_account_with() API to allow a callback to control whether to insert the loaded account into read_cache. #1350

Merged

pgarg66 reviewed May 14, 2024

View reviewed changes

svm/src/account_loader.rs Outdated Show resolved Hide resolved

pgarg66 reviewed May 14, 2024

View reviewed changes

accounts-db/src/accounts_db.rs Show resolved Hide resolved

pgarg66 reviewed May 14, 2024

View reviewed changes

svm/src/account_loader.rs Outdated Show resolved Hide resolved

HaoranYi commented May 16, 2024

View reviewed changes

svm/src/program_loader.rs Show resolved Hide resolved

HaoranYi mentioned this pull request Jun 6, 2024

get rid of get_account_meta #1620

Merged

HaoranYi removed the request for review from jeffwashington June 7, 2024 15:11

HaoranYi commented Jun 17, 2024

View reviewed changes

HaoranYi force-pushed the runtime/owner_check2 branch 2 times, most recently from cdc896b to 81bf453 Compare June 17, 2024 15:38

HaoranYi commented Jun 17, 2024

View reviewed changes

HaoranYi force-pushed the runtime/owner_check2 branch 2 times, most recently from dae3892 to 67c17ea Compare June 17, 2024 17:10

HaoranYi force-pushed the runtime/owner_check2 branch from 8391d59 to d977050 Compare June 20, 2024 13:49

HaoranYi force-pushed the runtime/owner_check2 branch from d977050 to 5764c5f Compare June 21, 2024 14:20

HaoranYi force-pushed the runtime/owner_check2 branch 3 times, most recently from 053166b to 8098948 Compare June 24, 2024 21:54

HaoranYi force-pushed the runtime/owner_check2 branch from 8098948 to 50d4708 Compare July 9, 2024 14:27

HaoranYi added 3 commits July 10, 2024 18:29

reorder load_account and program_cache replenish

25216d2

fix a test

07aea8f

rebase fixes

0ac1a61

HaoranYi force-pushed the runtime/owner_check2 branch from 50d4708 to 0ac1a61 Compare July 10, 2024 18:43

brooksprumo removed their request for review October 3, 2024 16:34

Lichtso closed this Dec 15, 2025

Conversation

HaoranYi commented May 2, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem

Summary of Changes

Performance Comparision

Uh oh!

codecov-commenter commented May 3, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

HaoranYi May 6, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Lichtso commented May 13, 2024

Uh oh!

HaoranYi commented May 13, 2024

Uh oh!

Lichtso commented May 13, 2024

Uh oh!

HaoranYi commented May 13, 2024

Uh oh!

Lichtso commented May 13, 2024

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

HaoranYi May 17, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

HaoranYi commented May 17, 2024

Uh oh!

alessandrod commented Jun 17, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

HaoranYi commented Jun 17, 2024

Uh oh!

HaoranYi Jun 17, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

HaoranYi commented Jun 17, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alessandrod commented Jun 20, 2024

Uh oh!

HaoranYi commented Jun 20, 2024

Uh oh!

HaoranYi commented Jun 21, 2024

Uh oh!

HaoranYi commented Jul 9, 2024

Uh oh!

apfitzge commented Aug 4, 2025

Uh oh!

Lichtso commented Aug 4, 2025

Uh oh!

HaoranYi commented May 2, 2024 •

edited

Loading

codecov-commenter commented May 3, 2024 •

edited

Loading

HaoranYi May 6, 2024 •

edited

Loading

HaoranYi May 17, 2024 •

edited

Loading

HaoranYi Jun 17, 2024 •

edited

Loading

HaoranYi commented Jun 17, 2024 •

edited

Loading