Skip to content
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

Cache a pointer to account_statistics_object in account object? #1095

Closed
abitmore opened this issue Jun 25, 2018 · 4 comments

Comments

Projects
3 participants
@abitmore
Copy link
Member

commented Jun 25, 2018

We've split account data into account_object and account_statistics_object for better performance when modifying, to reduce amount of data being copied to undo db. Due to this, we need to perform two queries when need data from both objects. By the way, this principle is abandoned in Steem.

Every time when looking for an account's statistics object after we already find the account object, we search from the root of the index, which is expensive especially when the index is large.

Since the address of the objects won't change after the block that they're created become irreversible, can we cache address of each other in the objects? For example, add an optional<account_statistics_object*> field in account_object class, when the account become irreversible, update the field to the address of responding account_statistics_object. And vise versa.

Same thing can be done for asset_object and dynamic_asset_data_object.

Thoughts?

@jmjatlanta

This comment has been minimized.

Copy link
Contributor

commented Jun 25, 2018

Just typing out loud here.. Can the objects be "down-cast" for undo db, and restored if the data in undo db needs to be used? That would save storage space in undo db, and keep the account_object whole for the (hopefully) normal case.

@pmconrad

This comment has been minimized.

Copy link
Contributor

commented Jun 27, 2018

At this time I think for the sake of stability we should avoid fiddling with pointers.

@jmjatlanta there isn't really a "normal case" for undo_db - incoming transactions are applied with an undo session that is rolled back before the next incoming block is applied. I. e. it is rolled back about as often as not. During replay undo_db is disabled anyway.

@abitmore abitmore added this to the 201812 - Feature Release milestone Dec 8, 2018

@abitmore abitmore added this to To do in Feature Release (201902) via automation Dec 8, 2018

@abitmore

This comment has been minimized.

Copy link
Member Author

commented Dec 8, 2018

This will be effectively fixed by #1462.

@abitmore abitmore moved this from To do to In progress in Feature Release (201902) Dec 8, 2018

@abitmore

This comment has been minimized.

Copy link
Member Author

commented Jan 1, 2019

Done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.