5 ms·

Eclipse shows you build errors by compiling your code in the background as you type. I believe you can disable this, or make it happen less frequently. This is

by Kliment 15y ago

Eclipse shows you build errors by compiling your code in the background as you type. I believe you can disable this, or make it happen less frequently. This is the cost of red wavy underlines for compile errors. I don't remember the exact setting, as I haven't used Eclipse in years, but it's in there.

icebraining 15y ago
But the Right Thing™ would be for Eclipse to lower the priority for such checks, so that they wouldn't conflict with the interface. I often have processes using all my available CPU time, but since they run at a 'niceness' value of 19, they don't affect the interactive tasks.
- bad_user 15y ago
  It's easier said than done -- whatever Eclipse is doing in the background, it also has to update the interface to reflect the latest results, which means synchronization with the UI thread. Also, a big project is hard to optimize, especially when threads are involved; so whatever shortcuts you take to make it work at first does come back to hunt you in a big way and you can't fix it easily. For example people are telling me that Eclipse should run fine, but on my laptop it freezes a lot, even for small projects; while IntelliJ IDEA works flawlessly. So I'm not sure what the problem is, but it does something on my box that it shouldn't -- and throwing more money on hardware (instead of searching for a better alternative) just seems like the wrong approach to me.
  - burgerbrain 15y ago
    I am under the impression that async UI updating is a rather solved problem. I'd wager Eclipse has even done it since.. probably forever. No, I suspect the real issue is that it doesn't 'renice' it's compilation processes correctly or sufficiently.
    - bad_user 15y ago
      Not necessarily -- if you're pushing thousands of update events in a short time, those events will also trigger a waterfall of other events triggered by UI components and so the effect gets multiplied; the end result being that it doesn't matter if the operations themselves are async as the UI will get sluggish. Another problem is that some operations are blocking in nature. Consider the case when an intellisense dialog is triggered (after typing a dot or pressing Ctrl-Space) -- to give you intellisense, Eclipse has to compile your code, make guesses about your intent in case the code has errors (since intellisense also has to function in case of simple errors, otherwise it is useless) and then present you with a dialog with options available for completion. This is not something that can be done async. Of course, this opinion was just some random guess. I have no idea why Eclipse has the tendency to freeze the UI on my machine.
kgthegreat 15y ago
Disable Build Auto in under Projects

by Kliment 15y ago

icebraining 15y ago

But the Right Thing™ would be for Eclipse to lower the priority for such checks, so that they wouldn't conflict with the interface. I often have processes using all my available CPU time, but since they run at a 'niceness' value of 19, they don't affect the interactive tasks.

bad_user 15y ago
It's easier said than done -- whatever Eclipse is doing in the background, it also has to update the interface to reflect the latest results, which means synchronization with the UI thread. Also, a big project is hard to optimize, especially when threads are involved; so whatever shortcuts you take to make it work at first does come back to hunt you in a big way and you can't fix it easily. For example people are telling me that Eclipse should run fine, but on my laptop it freezes a lot, even for small projects; while IntelliJ IDEA works flawlessly. So I'm not sure what the problem is, but it does something on my box that it shouldn't -- and throwing more money on hardware (instead of searching for a better alternative) just seems like the wrong approach to me.
- burgerbrain 15y ago
  I am under the impression that async UI updating is a rather solved problem. I'd wager Eclipse has even done it since.. probably forever. No, I suspect the real issue is that it doesn't 'renice' it's compilation processes correctly or sufficiently.
  - bad_user 15y ago
    Not necessarily -- if you're pushing thousands of update events in a short time, those events will also trigger a waterfall of other events triggered by UI components and so the effect gets multiplied; the end result being that it doesn't matter if the operations themselves are async as the UI will get sluggish. Another problem is that some operations are blocking in nature. Consider the case when an intellisense dialog is triggered (after typing a dot or pressing Ctrl-Space) -- to give you intellisense, Eclipse has to compile your code, make guesses about your intent in case the code has errors (since intellisense also has to function in case of simple errors, otherwise it is useless) and then present you with a dialog with options available for completion. This is not something that can be done async. Of course, this opinion was just some random guess. I have no idea why Eclipse has the tendency to freeze the UI on my machine.

kgthegreat 15y ago

Disable Build Auto in under Projects