-
Notifications
You must be signed in to change notification settings - Fork 25
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
less couts during advances in release mode #885
Conversation
WalkthroughWalkthroughThe changes involve a refactor of the logging mechanisms across multiple files, replacing standard output calls with structured logging macros such as Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant Logger
User->>Logger: Log initialization message
Logger->>Logger: Format message
Logger->>Logger: Output log
Assessment against linked issues
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
6521d48
to
847184f
Compare
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.
Actionable comments posted: 1
Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Files selected for processing (7)
- src/amr/level_initializer/hybrid_level_initializer.hpp (1 hunks)
- src/amr/messengers/hybrid_hybrid_messenger_strategy.hpp (2 hunks)
- src/amr/multiphysics_integrator.hpp (3 hunks)
- src/diagnostic/detail/h5writer.hpp (5 hunks)
- src/hdf5/detail/h5/h5_file.hpp (3 hunks)
- tests/diagnostic/test_diagnostics.hpp (3 hunks)
- tests/simulator/test_diagnostics.py (1 hunks)
Additional context used
Path-based instructions (6)
src/amr/level_initializer/hybrid_level_initializer.hpp (1)
Pattern
**/*.hpp
: Review the C++ code, point out issues relative to principles of clean code, expressiveness, and performance.src/hdf5/detail/h5/h5_file.hpp (1)
Pattern
**/*.hpp
: Review the C++ code, point out issues relative to principles of clean code, expressiveness, and performance.tests/diagnostic/test_diagnostics.hpp (1)
Pattern
**/*.hpp
: Review the C++ code, point out issues relative to principles of clean code, expressiveness, and performance.src/diagnostic/detail/h5writer.hpp (1)
Pattern
**/*.hpp
: Review the C++ code, point out issues relative to principles of clean code, expressiveness, and performance.src/amr/multiphysics_integrator.hpp (1)
Pattern
**/*.hpp
: Review the C++ code, point out issues relative to principles of clean code, expressiveness, and performance.src/amr/messengers/hybrid_hybrid_messenger_strategy.hpp (1)
Pattern
**/*.hpp
: Review the C++ code, point out issues relative to principles of clean code, expressiveness, and performance.
Additional comments not posted (16)
tests/simulator/test_diagnostics.py (1)
209-210
: LGTM!The change to accommodate semantic versioning is appropriate and aligns with common versioning practices.
The code changes are approved.
src/amr/level_initializer/hybrid_level_initializer.hpp (1)
60-60
: LGTM!The update to use
PHARE_LOG_LINE_STR
enhances logging consistency and integrates with the broader logging framework.The code changes are approved.
src/hdf5/detail/h5/h5_file.hpp (2)
Line range hint
46-50
: LGTM!The update to use
FileOp
instead ofunsigned
enhances type safety and clarity.The code changes are approved.
64-67
: LGTM!The update to use
FileOp
instead ofunsigned
maintains consistency and improves readability.The code changes are approved.
tests/diagnostic/test_diagnostics.hpp (4)
19-19
: LGTM!The change simplifies the file access logic and enhances clarity and type safety.
The code changes are approved.
50-50
: LGTM!The change enhances type safety and clarity by using
auto const
for theflags
parameter.The code changes are approved.
94-94
: LGTM!The change enhances const-correctness by making
out_
immutable after construction.The code changes are approved.
95-95
: LGTM!The change makes
flags_
more semantically meaningful and type-safe by usingHiFile::AccessMode const
.The code changes are approved.
src/diagnostic/detail/h5writer.hpp (4)
53-53
: LGTM!The change enhances clarity and type safety by using
HiFile::AccessMode::OpenOrCreate
.The code changes are approved.
59-59
: LGTM!The change enhances type safety and clarity by using
HiFile::AccessMode
for the_flags
parameter.The code changes are approved.
71-72
: LGTM!The change ensures consistency in handling file access modes by using
HiFile::AccessMode
for theflags
variable.The code changes are approved.
97-97
: LGTM!The change enhances type safety and clarity by using
HiFile::AccessMode
for thefile_flag
parameter.The code changes are approved.
src/amr/multiphysics_integrator.hpp (3)
317-319
: LGTM!The change standardizes the logging approach and potentially improves the output formatting and control by using
PHARE_LOG_LINE_STR
.The code changes are approved.
420-420
: LGTM!The change standardizes the logging approach and potentially improves the output formatting and control by using
PHARE_LOG_LINE_STR
.The code changes are approved.
514-517
: LGTM!The change standardizes the logging approach and potentially improves the output formatting and control by using
PHARE_LOG_LINE_STR
.The code changes are approved.
src/amr/messengers/hybrid_hybrid_messenger_strategy.hpp (1)
588-588
: LGTM!The change to use
PHARE_LOG_LINE_STR
instead ofstd::cout
aligns with the PR objective to reduce console output in release mode.The code changes are approved.
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.
Actionable comments posted: 0
Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Files selected for processing (3)
- src/amr/level_initializer/hybrid_level_initializer.hpp (1 hunks)
- src/amr/messengers/hybrid_hybrid_messenger_strategy.hpp (2 hunks)
- src/amr/multiphysics_integrator.hpp (3 hunks)
Files skipped from review as they are similar to previous changes (3)
- src/amr/level_initializer/hybrid_level_initializer.hpp
- src/amr/messengers/hybrid_hybrid_messenger_strategy.hpp
- src/amr/multiphysics_integrator.hpp
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.
lgtm, contains #883 and ok if you want for the simpler macro
9cc0634
to
c52f006
Compare
c52f006
to
cdc8d18
Compare
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.
Actionable comments posted: 2
Outside diff range, codebase verification and nitpick comments (2)
src/core/logger.hpp (1)
Line range hint
36-50
: Review thescope_log
structure for potential improvements.The
scope_log
structure uses rvalue references for its constructor parameters, which is unusual and might lead to confusion or errors if misused. Typically, structures like this should use const references unless there is a specific need to consume the passed arguments.Consider changing the constructor to take const references instead of rvalue references to avoid unnecessary complexity and potential bugs:
- scope_log(int&& i_, std::string&& str) + scope_log(const int& i_, const std::string& str) : i{i_} , key{str} { if (i <= LOG_LEVEL) { PHARE_LOG_START(i, key.c_str()); } }This change makes the code more robust by preventing unintended modifications to the original variables passed to the constructor.
src/amr/level_initializer/hybrid_level_initializer.hpp (1)
Line range hint
1-1
: Address TODO comments and review potential performance implications.While the code is generally well-structured and uses modern C++ practices, there are TODO comments that suggest incomplete areas that might need further attention. Additionally, considering the complexity of the operations within the
initialize
method, it would be beneficial to review the performance implications, especially in terms of memory and computational efficiency.Would you like me to help in addressing these TODO comments or perform a more detailed performance analysis?
Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Files selected for processing (4)
- src/amr/level_initializer/hybrid_level_initializer.hpp (1 hunks)
- src/amr/messengers/hybrid_hybrid_messenger_strategy.hpp (2 hunks)
- src/amr/multiphysics_integrator.hpp (3 hunks)
- src/core/logger.hpp (1 hunks)
Files skipped from review due to trivial changes (1)
- src/amr/messengers/hybrid_hybrid_messenger_strategy.hpp
Additional context used
Path-based instructions (3)
src/core/logger.hpp (1)
Pattern
**/*.hpp
: Review the C++ code, point out issues relative to principles of clean code, expressiveness, and performance.src/amr/level_initializer/hybrid_level_initializer.hpp (1)
Pattern
**/*.hpp
: Review the C++ code, point out issues relative to principles of clean code, expressiveness, and performance.src/amr/multiphysics_integrator.hpp (1)
Pattern
**/*.hpp
: Review the C++ code, point out issues relative to principles of clean code, expressiveness, and performance.
Additional comments not posted (4)
src/amr/level_initializer/hybrid_level_initializer.hpp (1)
60-60
: Refactor to structured logging approved.The replacement of a direct output statement with
PHARE_LOG_LINE_STR
is a positive change, aligning with the objectives to reduce console output verbosity and improve logging mechanisms. This change should help in better managing the log output, especially in production environments where excessive logging can be a performance issue.src/amr/multiphysics_integrator.hpp (3)
317-318
: Approved: Logging changes ininitializeLevelData
function.The replacement of
std::cout
withPHARE_LOG_LINE_SS
aligns with the PR's objectives to standardize logging and reduce console output in release mode.
418-418
: Approved: Logging changes inapplyGradientDetector
function.The replacement of
std::cout
withPHARE_LOG_LINE_STR
aligns with the PR's objectives to standardize logging and reduce console output in release mode.
512-514
: Approved: Logging changes inadvanceLevel
function.The replacement of
std::cout
withPHARE_LOG_LINE_SS
aligns with the PR's objectives to standardize logging and reduce console output in release mode.
#else | ||
#define PHARE_LOG_LINE_STR(str) | ||
#define PHARE_LOG_LINE_SS(str) |
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.
Ensure macro definitions are consistent across build configurations.
The macro PHARE_LOG_LINE_SS
is defined differently based on the build configuration. It's important to ensure that the macro behaves consistently or is disabled appropriately across different configurations to prevent runtime errors and maintain code clarity.
Verify that the macro is either consistently defined or appropriately disabled across all configurations. If disabling is the choice, ensure that it does not lead to any unresolved references during compilation in release mode.
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.
this is so we do not print lines during release mode with -DNDEBUG
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.
@PhilipDeegan, thank you for the clarification. The conditional definition of the macro makes sense to avoid unnecessary logging in release mode with -DNDEBUG
. This approach is indeed appropriate for optimizing performance and reducing output clutter in production environments.
@@ -15,8 +15,10 @@ | |||
#if !defined(NDEBUG) || defined(PHARE_FORCE_DEBUG_DO) | |||
#define PHARE_LOG_LINE_STR(str) \ | |||
std::cout << __FILE__ << ":" << __LINE__ << " - " << str << std::endl; | |||
#define PHARE_LOG_LINE_SS(s) PHARE_LOG_LINE_STR((std::stringstream{} << s).str()); |
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.
Refactor the macro parameter for consistency.
The macro PHARE_LOG_LINE_SS
uses s
as a parameter, which is inconsistent with the change noted in the alterations summary that suggests it should be str
. This inconsistency can lead to confusion and potential errors in macro usage.
Consider renaming the parameter to match the intended usage and documentation:
-#define PHARE_LOG_LINE_SS(s) PHARE_LOG_LINE_STR((std::stringstream{} << s).str());
+#define PHARE_LOG_LINE_SS(str) PHARE_LOG_LINE_STR((std::stringstream{} << str).str());
Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
#define PHARE_LOG_LINE_SS(s) PHARE_LOG_LINE_STR((std::stringstream{} << s).str()); | |
#define PHARE_LOG_LINE_SS(str) PHARE_LOG_LINE_STR((std::stringstream{} << str).str()); |
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.
because it's a macro, it would not be advisable to use the input parameter str
as it might conflict with the stringstream::str()
call
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.
@PhilipDeegan, you're absolutely right. Using str
as a parameter name in the macro could indeed lead to conflicts with the stringstream::str()
method. Keeping the parameter name as s
is the best approach to avoid any potential issues. Thanks for the clarification!
closes #865
Summary by CodeRabbit
New Features
Bug Fixes
Documentation