Omit dependencies' debug info #2803
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Have you tried to get a backtrace, especially in tokio task? I assume they should still be reasonable (showing info for our code), but just to check. Checking compilation time would also be interesting. |
arssher
reviewed
Nov 14, 2022
|
I've added this diff --git a/pageserver/src/walreceiver.rs b/pageserver/src/walreceiver.rs
index 1fad91c8..9f74d982 100644
--- a/pageserver/src/walreceiver.rs
+++ b/pageserver/src/walreceiver.rs
@@ -131,6 +131,9 @@ impl<E: Clone> TaskHandle<E> {
}
async fn next_task_event(&mut self) -> TaskEvent<E> {
+ if true {
+ panic!("((((");
+ }
match self.events_receiver.changed().await {
Ok(()) => TaskEvent::Update((self.events_receiver.borrow()).clone()),
Err(_task_channel_part_dropped) => {and run a random Pytest test that writes data with |
|
Cool! |
arssher
approved these changes
Nov 14, 2022
|
I've tried building on the same VM I have without doing anything else, first the regular project then the patched one, first removing
Old code: New code: |
Co-authored-by: Arseny Sher <[email protected]>
|
Cool! I'm a little worried even this might make debugging harder; sometimes it would be useful to step into and dig deeper into dependencies, too. We have a lot of dependencies and they're not all mainstream enough that we can really assume that they're bug-free. And I wonder how this affects code generated for generics defined in a dependency, but used in our code. But I have to admit that this is such a big saving that we should probably go ahead and do it anyway. |
|
For comparison, the trace from the "old" project with all debug info and the same I definitely see more info, but it's relatively useless for me most of the time. Agree, that stepping into our dependencies' code in GDB feels good to have, wondering, how frequent do we need such option generally? If |
Yeah, I think that's a good tradeoff. |
hlinnaka
approved these changes
Nov 14, 2022
funbringer
approved these changes
Nov 14, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Based on https://neondb.slack.com/archives/C0277TKAJCA/p1668079753506749
I did not measure build times properly, since run multiple compilations in parallel, but did not notice drastic compile time increases. CI could show more, presumably needs its cache repopulated first.
Mac build difference could be explained by them having debug symbols split off by default in Cargo:
rust-lang/cargo#9298
https://blog.rust-lang.org/2021/03/25/Rust-1.51.0.html#splitting-debug-information
Debug symbols seems to be present still for the binaries with the changes: