On 17/09/2013 15:19, Manu wrote:
On 17 September 2013 23:46, Bruno Medeiros
<[email protected] <mailto:[email protected]>>
wrote:
On 17/09/2013 07:24, Manu wrote:
I closed about half my open tabs after my last email
(~50 left
open). Down
to 93mb. You must all use some heavy plugins or something.
My current solution has 10 projects, one is an entire game
engine with over
500 source files, hundreds of thousands of LOC.
Intellisense
info for all
of it... dunno what to tell you.
Eclipse uses more than 4 times that much memory idling
with no
project open
at all...
4 times ? You must have a pretty light instance of eclipse !
It's a fairly fresh eclipse install, and I just boot it up. It
showed
the home screen, no project loaded. It was doing absolutely
nothing and
well into 400mb.
When I do use it for android and appengine, it more or less
works well
enough, but the UI feels like it's held together with stickytape and
glue, and it's pretty sluggish. Debugging (native code) is slow and
clunky. How can I take that software seriously?
I probably waste significant portion of my life hovering and
waiting for
eclipse to render the pop-up variable inspection windows. That shit
needs to be instant, no excuse. It's just showing a value from ram.
Then I press a key, it doesn't take ages for the letter to
appear on the
screen...
Android and Appengine?
There are two flaws in that comparison, the first is that apparently
you are comparing an Eclipse installation with a lot more tools than
your VS installation (which I'm guessing has only C++ tools, perhaps
some VCS tools too?). No wonder the footprint is bigger. For
example, my Eclipse instance with only DDT and Git installed, and
opened on a workspace with D projects takes up 130Mb:
http://i.imgur..com/VmKzrRU.png <http://i.imgur.com/VmKzrRU.png>
My VS installation has VisualD, VCS tools, xbox 360, ps3, android,
emsscripten, nacl, clang and gcc tools. (I don't think these offer any
significant resource burden though, they're not really active processes)
If Eclipse has a lot more tools as you say, then it's a problem is that
I never selected them, and apparently they hog resources even when not
being used. That seems like a serious engineering fail if that's the case.
As far as I know, I don't have DDT and git installed, so you're 2 up on
me :) .. I only have android beyond default install (and no project was
open). No appengine in this installation.
Eclipse is designed such that plugins should be lazy-loaded: they are
only loaded when needed (for example if you open a
view/editor/preference-page/project, etc., contributed from a plugin).
But that requires the plugin to be well-behaved in that regards, and
some plugins might not be so.
I'm not familiar at all with the Eclipse Android plugins or AppEngine
plugins so I have no idea how these behave performance wise. I can't
comment on that. Again it should noted that Eclipse is not a monolithic
application, and a lot of things are going to depend on what
plugins/tools you have installed. (neither is VisualStudio a monolithic
application, but I would argue that Eclipse has more plugins and
extensions available, and thus more variation in setup and quality of
installations)
With the recommend JVM memory settings (see
http://code.google.com/p/ddt/__wiki/UserGuide#Eclipse_basics
<http://code.google.com/p/ddt/wiki/UserGuide#Eclipse_basics> ), the
usage in that startup scenario goes up to 180Mb.
But even so that is not a fair comparison, the second flaw here is
that Eclipse is running on a VM, and is not actually using all the
memory that is taken from the OS.
It's perfectly fair. Let's assume for a second that I couldn't care less
that it runs in a VM (I couldn't), all you're really saying is that VM's
are effectively a waste of memory and performance, and that doesn't
redeem Eclipse in any way.
You're really just suggesting that Eclipse may be inherently inefficient
because it's lynched by it's VM. So there's no salvation for it? :)
If you wanna see how much memory the Java application itself is
using for its data structures, you have to use a tool like jconsole
(included in the JDK) to check out JVM stats. For example, in the
DDT scenario above, after startup the whole of Eclipse is just using
just 40Mb for the Java heap:
http://i.imgur..com/yCPtS52.png <http://i.imgur.com/yCPtS52.png>
I don't care how much memory the app is 'really' using beneath it's
overhead. All I care about is how much memory it's using (actually, I
don't really care about that at all, I only care about how it performs,
which is poorly), and the windows task manager surely offers the most
fair measure for comparison available to the OS, at least for the memory
consumption metric ;) ..
The Java VM overhead is a valid overhead, I'm not dismissing it
entirely. But looking back on your comments, it appears you are implying
that if your Eclipse installation takes up 400Mb of process memory in
the Windows Task Manager, with an empty workspace, then if you had a
workspace of the same size as you have in VisualStudio ("solution has 10
projects", etc.) then Eclipse memory usage would just explode. But that
is not a fair measure:
The VM overhead is linear to the size of the plugins of your Eclipse
installation. It's not gonna grow in proportion to the data you have on
your workspace though. Only the Java heap of Eclipse would be expected
to grow in proportion to the Eclipse workspace size. That's why I was
pointing out the Java heap memory usage.
The problem remains that I find eclipse
significantly less responsive, and the UI is messy and disorganised. I
feel a lack of coherency between different parts of Eclipse.
So in summary, I prefer and use VS whenever I have the option.
That said, I do agree that Eclipse is generally slower than Visual
Studio. Eclipse (and most existing plugins) are almost entirely
Java-based, which has some JIT and GC overheards. Whereas VS is done in
C++ and C# (I'm guessing a lot of critical bits are developed in C++, at
least for VS2010).
But I don't think Eclipse is as bad or as slow as a lot of people make
it appear to be. And better functionality would make up for it, for sure.
--
Bruno Medeiros - Software Engineer
