11 ms·
Speeding up the Rust edit-build-run cycle
- renewiltord 2y agoGood set of tips. Thank you.
- Comma2976 2y agoIt was my pleasure.
- omani 2y agothanks
- nuudlman 2y agoNot linking debug info must be some kind of sick joke. What is the point of a debug build without symbols?
- 0x457 2y agoEnable them when you need to debug. This is for speeding up "edit-build-run" workflows.
- nuudlman 2y agoIt's a lot faster to add a log point in a debugger than to add a print statement and recompile. Especially with cargo check, I really don't see the point of non-debuggable builds (outside of embedded, but the size of debuginfo already makes that a non-starter).
- 0x457 2y agoYes, but we're talking about time spent with "add a print statement and recompile" vs time saved by not including debuginfo on every other build. You have to do that comparison yourself.
- RichardLake 2y agoDoesn't rust have overflow checks in debug and skips them in release?
- 0x457 2y agoRust has compiled time overflow checks enabled by default in any profile. Runtime overflow checks are disabled by default in release profile.
- vbezhenar 2y ago1. Skipping some optimizations to build faster. 2. Conditionally compiling some code like logging (not sure if matters for typical Rust projects, but for embedded C projects it's typical). 3. Conditionally compiling assertions to catch more bugs. I'm using logs, because debugger breaks hardware. Very rarely do I need to reach debugger. Even when hard exception occurs, usually enough info is logged to find out the root cause of the bug.
- vlovich123 2y ago> because debugger breaks hardware What? Seems like you’re talking about embedded but I’ve done a lot of embedded projects in my time and I’ve never had a debugger that breaks the HW.
- viraptor 2y agoDepends what you're working on. Stopped in an unfortunate place? That one element didn't get turned off and burned out. Or the motor didn't stop. Or the crucial interrupts got missed and your state is now reset. Or...
- bippihippi1 2y agoare there debugging tools specifically for situations like that? do you just write code to test manually? How do you ensure dev builds don't break stuff like that even without considering debugging?
- rcxdude 2y agoThe most useful tool is a full tracing system (basically a stream of run instructions you can use to trace the execution of the code without interrupting it), but unfortunately they're quite expensive and proprietery, and require extra connections to the systems that do support them, so they're not particularly commonly used. Most people just use some kind of home-grown logging/tracing system that tracks the particular state they're interested in, possibly logged into a ringbuffer which can be dumped when triggered by some event.
- ryangs 2y ago>Debug information tends to be large and linking it slows down linking quite considerably. If you’re like many developers and you generally use println for debugging and rarely or never use an actual debugger, then this is wasted time. Interesting. Is this true? In my work (java/kotlin, primarily in app code on a server, occasional postgres or frontend js/react stuff), I'm almost always reaching for a debugger as an enormously more powerful tool than println debugging. My tests are essentially the println, and if they fail for any interesting reason I'll want the debugger.
- Aurornis 2y agoprintln debugging is where everyone starts. Some people never graduate to knowing how to use a debugger. Debugging through log data still has a place, of course. However, trying to do all of your debugging through println is so much harder, even though it feels easier than learning to use a debugger.
- 0x457 2y agoTo be fair, if your code is multithreaded and sensitive to pauses, it becomes harder to debug with a debugger. Ultimately, if you have a good logging setup and kinda know where the issue is a quick log message could be faster than debugging if all you want to do is look a variable value.
- pjmlp 2y agoThat is where OS tracing like DTrace and ETW come into play, which can then be loaded into a debugging session.
- kaba0 2y agoLogging can change timing issues though. There are too many cases where an added log statement "fixed" a race condition, simply by altering the timing/adding some form of synchronization inherent in the logging library.
- 2y ago
- Aurornis 2y ago> If you’re like many developers and you generally use println for debugging and rarely or never use an actual debugger You lost me here. Using a debugger to step through the code is a huge timesaver. Inserting println statements, compiling, running, inserting more println, and repeating is very inefficient. If you learn to use a debugger, set breakpoints, and step through code examining values while you go then the 8 seconds spent compiling isn’t an issue.
- Ar-Curunir 2y agoJust ignore that part then? You don't have to stop reading the rest of the (very good) article lol.
- sunshowers 2y agoStep through debuggers and tracers are two different dimensions of debugging, and not directly comparable.
- fmbb 2y ago> Inserting println statements, compiling, running, inserting more println, and repeating is very inefficient. That all depends on how long it takes to compile and run. > If you learn to use a debugger, set breakpoints, and step through code examining values while you go then the 8 seconds spent compiling isn’t an issue. Meh, it's fine. You still have to set new ones and re-run your code to trigger the reproduction iteratively if you don't know where anything is wrong. Clicking "add logging break point here" and adding a print statement is really not very different. In my experience the hard part is know where you want to look. Stepping through all your code line by line and looking at all values every step is not a quick way to do anything. You have to divide and conquer your debugging smartly, like a binary search all over your call sites in the huge tree-walk that is your program.
- forrestthewoods 2y agoStepping through code and adding breakpoints is a spectacular way to figure out where to put log statements. Modern code is so abstract that it’s nigh impossible to figure out what the fuck function even gets called just from looking at code.
- forrestthewoods 2y ago[flagged]
- tel 2y agoJust my lack of experience here, but I'm trying to verify I'm successfully using sold. The mold linker claims it leaves metadata in the .comment section, but on mach-o does that exist? Is there a similar evaluation command using objdump as the mold readelf command?
- joshka 2y agoLast time I tested mold/sold on Mac, there was no measurable time difference.
- James_K 2y agoSurely it would be better to use a debugger and avoid recompiling your code for the added print statements than to strip out the debug information to decrease build times.
- evrimoztamur 2y agoI build wasm as a target and this is sadly not an option, I have to rebuild for each little bit. I will be trying a different linker and see how it goes though!
- khuey 2y agosplit-debuginfo = "unpacked" (-gsplit-dwarf for C/C++) is the way. Your tools (debuggers, profilers, etc) probably support it by now.
- sendomatic 2y agoThere are a lot of different t views on debugging with a debugger vs print statements and what works better. This often seems to be based on user preference and familiarity. One thing that I haven’t seen mentioned is for issues with dependencies. Setting up a path dep in rust or fetching the code in whatever language you’re using for your project usually takes more time than simply adding some breakpoints in the library code.
- zerd 2y agoThis post is from February, any interesting changes/improvements since then? Progress on “wild”?
- DylanSp 2y agoLooks like he's been continuing to work on it. GitHub repo: https://github.com/davidlattimore/wild https://github.com/davidlattimore/wild List of his blog posts, a couple of which are about wild: https://davidlattimore.github.io/ https://davidlattimore.github.io/
- Arch-TK 2y ago> ~/.cargo/ This reminds me... STOP putting your shitty dot-directories full of a mix of config, cache and data in my god damned home directory. Concerned that not doing this will break things? Just check if you've dumped your crap in there already and if not then put it in the right places. Worried about confusing existing users migrating to other machines? Document the change. Still worried? How about this: I'll put a file called opt-into-xdg-base-directory-specification inside ${XDG_CONFIG_HOME:-$HOME/.config} and if you find that file you can rest assured I won't be confused. Thanks in advance!
- pvinis 2y agoI would upvote at least 10 times if I could. This!
- childintime 2y agoIf you have to blame the developer, blame the OS. Shit drops down from above. Maybe it's just old and crappy.
- HdS84 2y agoAs a non linux expert I always wonder where to put crap - most places seem not fit for purpose.
- seanhunter 2y agoThere is a standard which you should follow. Here you go https://specifications.freedesktop.org/basedir-spec/latest/ https://specifications.freedesktop.org/basedir-spec/latest/
- childintime 2y agoYep, likely an example of downstream problems that should not exist.
- johnisgood 2y agoBlame the OS? Why? And what good would that do? The developers could have used XDG_CONFIG_HOME at the very least.
- mdaniel 2y agoIt's funny that two different posts today are having the same "tabs vs spaces" about "printf vs debugger" https://news.ycombinator.com/item?id=42146338 https://news.ycombinator.com/item?id=42146338 (Seer: A GUI front end to GDB for Linux)