Eclipse Git gets faster – UI freeze reporting activated by default in saneclipse

I love our new platform.ui UI freeze reporting in Eclipse 4.5 which was contributed by Google.

Git in Eclipse gets faster soon, thanks to the amazing reaction time of Robin Stocker and Matthias Sohn and our new Eclipse platform UI freeze monitor. See for example Gerrit review for one of the improvements.

If you want to help to make Eclipse faster, simply download the latest Eclipse 4.5 milestone or integration build and activate it via its preferences.


Afterwards you received entries in the Eclipse error log about UI freeze. If you see a freeze please report it via Eclipse Bugzilla.

As we think the tooling is extremely useful we have activate it by default via our saneclipse plug-in.

Matthias Sohn contacted me with the info that Andrey Loskutov also fixed several issues found with the UI performance monitor. (UI freeze fix)

A big thanks to Andrey also!

About Lars Vogel

Lars Vogel is the founder and CEO of the vogella GmbH and works as Eclipse and Android consultant, trainer and book author. He is a regular speaker at international conferences, He is the primary author of With more than one million visitors per month this website is one of the central sources for Java, Eclipse and Android programming information.
This entry was posted in Eclipse, Lars Vogel. Bookmark the permalink.

3 Responses to Eclipse Git gets faster – UI freeze reporting activated by default in saneclipse

  1. Michael Keppler says:

    Can someone elaborate on best practices when to use the…) as in the first linked change? Up to now I basically always created Eclipse jobs to split potentially long running tasks from the current operation, and I didn’t know ModalContext at all.

  2. Dennis says:

    Any disk IO or network API stack should be banned in the main UI therad.

    But seems few GIT or SVN plugins do a lot. They know caching won’t help.

  3. @Michael: if you follow the review you will see that in most cases you won’t use ModelContext, there are many better suitable ways to run long running tasks. with fork == false doesn’t make sense at all (just directly runs the task in same thread). with fork == true main points:
    * Runs given task in different thread (sometimes, see below)
    * If called from ModalContextThread, runs in the same thread (nested tasks share same thread)
    * Blocks caller thread
    * If called from UI thread, will run event loop while waiting on the task!
    * Always flushes UI event loop after task execution

    BUT it does not signal to user in any way that the task is running and it does not gives any UI to cancel the task.

Comments are closed.