Had another 48hr game jam this weekend...

[PauloPinto]

On Tuesday, 17 September 2013 at 15:15:09 UTC, Bruno Medeiros 
wrote:
> On 17/09/2013 15:19, Manu wrote:
>> On 17 September 2013 23:46, Bruno Medeiros
>> <brunodomedeiros+dng at gmail.com 
>> <mailto:brunodomedeiros+dng at gmail.com>>
>> 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.

It is mostly C# actually.

The VS 2010 rewrite was a way to fix WPF bugs and prove the 
developers at large that big applications could be done in WPF.

As far as I can tell from MSDN blogs, the only C++ bits left 
standing were the ones related to C++ development.

This most likely changed with the whole "Going Native" story 
afterwards.

--
Paulo