Eclipse Gems, Tips & Tricks: Faster Debugger Start

Posted on by

This article is part of a ‘mini series’ about hidden gems, tips and tricks around Eclipse.
The topic of this one is how to accelerate the start of the debugger.

Nothing to be done

Nothing to be done

I’m probably a ‘classic’ developer, using the ‘edit – compile – debug’ cycle. The thing is that by default in Eclipse, when I press ‘debug’ it does a ‘compile’ again. That’s fine for the developer who just wants to do a ‘edit – debug’, but again this is not me.

In my case that extra ‘compile’ even if nothing needs to be compiled can take multiple seconds especially on the larger projects I’m working on. The reason is that the ‘build’ kicks off the make process and this goes through all the make files and checks for changes which needs time.

Nothing to be done

Nothing to be done

But it is not only that 216ms shown above: the hole process can take several seconds. So saving these seconds multiple times a day really can make a difference.

Luckily there is a setting to avoid this: It is under Window > Preferences > Run/Debug > Launching, disable the ‘Build (if required) before launching‘:

Disabled Build before launching

Disabled Build before launching

Of course: make sure you have done a ‘compile’ before the ‘debug’, otherwise you won’t debug what you have as sources in the project. With great power comes great responsibility ;-).

Happy Debugging 🙂

Links

 

18 thoughts on “Eclipse Gems, Tips & Tricks: Faster Debugger Start”

  1. Erich,

    Can I say that it’s *really* dangerous to depend on Eclipse (or any automated system) to determine when a build is necessary? I’ve experienced cases where Eclipse (including CW and MCUXpresso variants as well as C/C++ and Java versions) have missed including changes because they weren’t saved by the developer as well as cases that that were changed, saved and then reverted back to the original or a previous version that are passed to the compiler.

    I make it a rule to make sure all source tabs are saved (not marked with “*”), do a “Clean” and then “Build Project” followed by “Debug” – yes it takes a few extra seconds but that saves minutes trying to figure out why the code isn’t working as I expect it to.

    myke

    Like

    Reply ↓

    • There’s been a few times when MCUXpresso has lost track of my project files, ending up with the code and variable definitions being out of sync – horrifying bugs till I eventually work it out!
      Happily it’s very rare, but maybe that’s worse since it takes longer to think of the possibility.

      Like

      Reply ↓

    • I consider not saving files as ‘user error’. Eclipse has the default setting to ‘save files before build’ which I never would disable except for very good reasons.
      And I trust the build system: A clean is what I do whenever I import files/projects. Because the build system depends on file dates, the only problems I have seeing is with wrong file time stamps e.g. if they were copied/moved from a different system (e.g. from Linux to a Windows host and the time zone was not right). Having said that: no (build) system is perfect, nor is the human. What helps for sure is to have a understanding how the system works.

      Like

      Reply ↓

  2. Pingback: Eclipse Gems, Tips & Tricks: Black Theme | MCU on Eclipse

  3. Pingback: Eclipse Gems, Tips & Tricks: Project Filter | MCU on Eclipse

  4. Pingback: Eclipse Gems, Tips & Tricks: Text Block Selection | MCU on Eclipse

  5. Pingback: Eclipse Gems, Tips & Tricks: RT(F)M | MCU on Eclipse

  6. Pingback: Eclipse Gems, Tips &Tricks: Show in System Explorer | MCU on Eclipse

  7. Pingback: Eclipse Gems, Tips & Tricks: Open Declaration | MCU on Eclipse

  8. Pingback: Eclipse Gems, Tips & Tricks: Code Completion | MCU on Eclipse

  9. Pingback: Eclipse Gems, Tips & Tricks: Highlight Usage and Definition | MCU on Eclipse

  10. Pingback: Eclipse Gems, Tips & Tricks: Block Comments | MCU on Eclipse

  11. Pingback: Eclipse Gems, Tips & Tricks: Working Sets | MCU on Eclipse

  12. Pingback: Eclipse Gems, Tips & Tricks: Close and Open Projects | MCU on Eclipse

  13. Pingback: Eclipse Gems, Tips & Tricks: Importing Projects | MCU on Eclipse

  14. Pingback: Eclipse Gems, Tips & Tricks: Code Folding | MCU on Eclipse

  15. Better is to setup duplicate debug configurations without the “auto build” option, so you can choose between them on the fly.

    Currently I’m using Simplicity Studio v4. I’m not sure what versions of Eclipse/CDT it is based on.

    Right click project –> Debug As –> Debug Configurations…
    Right click the debug config, choose “Duplicate”. Rename it in the “Name” field on the right (I usually add a ” – RERUN” suffix), and select “Disable auto build” as shown above.

    When multiple debug configurations exist for the same executable, it will prompt you to choose which to use upon starting the debugger. I use the one with auto build by default, and the one without when I know I just built it and want to reload the same thing. (It’s especially useful for troubleshooting halt issues that break the debugger reset.)

    Like

    Reply ↓

What do you think?

This site uses Akismet to reduce spam. Learn how your comment data is processed.