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

Refactored wallet.cpp file because was too big (issue #950) #1413

Closed
wants to merge 13 commits into from

Conversation

cogutvalera
Copy link
Member

This PR for #950 issue wallet.cpp file too big

@cogutvalera cogutvalera mentioned this pull request Nov 1, 2018
9 tasks
@jmjatlanta
Copy link
Contributor

jmjatlanta commented Nov 1, 2018

Ironically, this change led my compiler to memory exhaustion. Previous builds were close, this build pushed it over the edge. 7 processors, 16GB RAM, 6GB Swap. Recompiling with fewer processors got it to compile. cli_test and chain_test ran without errors. Now reviewing the code.

@cogutvalera
Copy link
Member Author

@jmjatlanta Thank you very much !

@cogutvalera
Copy link
Member Author

@jmjatlanta FYI if you will try to start cli_wallet without merging this PR bitshares/bitshares-fc#86 then you will catch SEGFAULT

Copy link
Contributor

@jmjatlanta jmjatlanta left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need to move 1 method, and looking for comments from others.

libraries/wallet/implementation/wallet_network_impl.cpp Outdated Show resolved Hide resolved
@@ -79,163 +80,27 @@
# include <sys/stat.h>
#endif

#include "wallet_account.cpp"
Copy link
Contributor

@jmjatlanta jmjatlanta Nov 5, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need to be careful here. If make compiles these as objects (i.e. cmake tells it to), linkers will not be able to link.

This is certainly a way to fix the issue reported, and the precompiler will do its job. But I wonder if this is the best way to fix it. Honestly, I would break these into separate classes (ACID principle), but that would require a larger effort. Perhaps @abitmore or @pmconrad or @oxarbitrage have ideas on how it could be done.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks ! My solution requires minor changes just to separate different logical parts in different files like for example database.cpp implementation.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good, but then please also use the same mechanism as used for database.cpp: https://github.com/bitshares/bitshares-core/blob/master/libraries/chain/CMakeLists.txt#L11-L30 (can use the same constant).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok sure ! Thanks !

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@cogutvalera
Copy link
Member Author

Bumped FC library to fix conflicts

@cogutvalera
Copy link
Member Author

I've added mechanism as used for database.cpp, so is all fine now ? What are your thoughts guys ?
IMHO we can merge and close this PR and it's related issue, right ?

@pmconrad
Copy link
Contributor

Have you tested disabling the unity build? It doesn't compile for me.

@pmconrad
Copy link
Contributor

This is a PITA to review.
Next time you tackle such a huge refactoring please do it in small steps in individual commits that are easily verifiable.

@cogutvalera
Copy link
Member Author

This is a PITA to review.
Next time you tackle such a huge refactoring please do it in small steps in individual commits that are easily verifiable.

ok sure ! sorry ! Thanks !

@cogutvalera
Copy link
Member Author

Have you tested disabling the unity build? It doesn't compile for me.

I've tested with unity build enabled only and all compiled well enough without any errors detected.
Checking now again but with unity build disabled at this time ... give me just a bit time and I will make new commit with fix if there is something wrong. Also do we need case with unity build disabled or maybe should I remove it ?

Copy link
Contributor

@pmconrad pmconrad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still working on the implementation/*cpp files.

return my->broadcast_transaction(tx);
}

signed_transaction wallet_api::sign_transaction(signed_transaction tx, bool broadcast /* = false */)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please move to general.

return fc::to_hex(fc::raw::pack(tx));
}

pair<transaction_id_type,signed_transaction> wallet_api::broadcast_transaction(signed_transaction tx)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please move to general.

return my->remove_builder_transaction(handle);
}

string wallet_api::serialize_transaction( signed_transaction tx )const
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please move to general.

return my->cancel_order(order_id, broadcast);
}

signed_transaction wallet_api::global_settle_asset(string symbol,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please move to asset.

@@ -0,0 +1,524 @@
/*
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please rename to wallet_stealth.cpp

return my->upgrade_account(name,broadcast);
}

fc::ecc::private_key wallet_api::derive_private_key(const std::string& prefix_string, int sequence_number) const
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please move to general.

return my->_remote_db->get_full_accounts({name_or_id}, false)[name_or_id];
}

vector<limit_order_object> wallet_api::get_account_limit_orders(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please move to trading.

return graphene::wallet::utility::suggest_brain_key();
}

vector<brain_key_info> utility::derive_owner_keys_from_brain_key(string brain_key, int number_of_desired_keys)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO this utility method belongs into the _impl file.

return results;
}

brain_key_info utility::suggest_brain_key()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO this utility method belongs into the _impl file.

* THE SOFTWARE.
*/

#include "implementation/wallet_transaction_builder_impl.cpp"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO including .cpp files from other .cpp doesn't really fulfill the goal of #950.
Yes, the individual files get smaller, but they are not independent. An IDE must load all included files as well to provide auto-completion for example, so splitting and including doesn't reduce memory requirements. Same for the compiler.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see you have already partially made this separation. Perhaps it is sufficient to remove these includes and compile the *_impl separately.

@pmconrad
Copy link
Contributor

Also do we need case with unity build disabled or maybe should I remove it ?

I have switched to using it by default in my setup, as my impression is that it speeds up the build. Especially when modifying only one of the .cpp files.

No need to add a specific test IMO. Once it's set up correctly it should continue to work.

@cogutvalera
Copy link
Member Author

ok, thanks ! soon will make new commits with improvements ...

@oxarbitrage oxarbitrage mentioned this pull request Nov 12, 2018
34 tasks
@cogutvalera
Copy link
Member Author

all improvements done already, also thinking and trying to optimize more compilation memory and time

@cogutvalera
Copy link
Member Author

cogutvalera commented Nov 13, 2018

still thinking about more optimizing build time and memory, is it possible to extend estimation for this optimization @ryanRfox ? or maybe should I open another new issue for this optimization task ?

PS: #950 was intended to reduce file size towards smaller files with code, but not to optimize memory and time compilation

Thanks !

@cogutvalera
Copy link
Member Author

created new issue for deeper wallet library refactoring #1432

@pmconrad
Copy link
Contributor

Confirmed that as of f321f43 code was only moved around. No functional changes.

@cogutvalera
Copy link
Member Author

Thank you very much ! Really appreciate all core team's time and efforts !
Now and in future will do only such atomic commits so it would be easier for reviewers to see my changes in step-by-step approach.

Thanks !

@cogutvalera
Copy link
Member Author

can we merge it ? so I can start working on #1432 based on this merge.
Or what are your thoughts ? Advise please.
Thanks !

@cogutvalera
Copy link
Member Author

Guys what should we do with this PR ? Look please when you will have time.

@abitmore
Copy link
Member

abitmore commented Aug 2, 2019

This branch has conflicts that must be resolved.

@abitmore abitmore added this to New -Awaiting Core Team Evaluation in Project Backlog via automation Aug 2, 2019
@abitmore abitmore added this to the Future Feature Release milestone Aug 2, 2019
@jmjatlanta jmjatlanta mentioned this pull request Sep 23, 2019
3 tasks
@abitmore
Copy link
Member

Closing in favor of #2013.

@abitmore abitmore closed this Sep 29, 2019
@abitmore abitmore removed this from New -Awaiting Core Team Evaluation in Project Backlog Oct 7, 2019
@abitmore abitmore removed this from the Future Feature Release milestone Oct 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants