High CPU usage in Eclipse

Hi, I have a problem when I try to make a simple app in Eclipse. Even it is sample application from tutorial after run my CPU usage is about 65-85%. I looking for similar problem, and found it when someone is using NetBeans. But didn’t find solution. Where can be problem?

i had this problem, but not only with jme, with big project too. disable hyperlinking, content assist and occurence marking. should solve your problem :slight_smile:

I disabled content assist and occurence marking but that didn’t solve the problem. How to disable hyperlinking in eclipse? I cannot see option with this name. Or maybe this is not an option?

@caro: Do you mean with “after run” that if you have started the sample application your cpu is going up?

window-Preferences->editors->hyperlinking
but there r something more to do, just don’t recal :confused: try searching in eclipse forums
i usually get this when working with complicated frameworks or when file is more than 5k lines

@ceiphren: Yes, that’s exactly what I mean.
@eraslt: Disable hyperlinking doesn’t help :-/ I’m looking for forums don’t find anything yet…

@caro: That’s pretty normal as video games are running in a loop that runs as fast as your cpu is capable. Try running any other game (make sure that vsync isn’t active) and you will see how your cpu will run nearly at full speed (depending on the core count).

You can control this a little bit by limiting the fps count in the settings object but as your game grow every loop cycle will become more and more expensive. Also every gamer out there has a different hardware config so the best thing is not to touch the frame count.

regards,

ceiphren

But in sample application from tutorial which drawing square and user can move it? I have core2 duo processor so I think this is not normal.
Anyway, I changed workspace, download different eclipse installation but this don’t resolve problem.
On Ubuntu 10.04 this problem doesn’t occur so it is for sure eclipse error on Windows 8 64 bit.
If i won’t find solution I will be using jmonkey projects on linux, but this is not really comfortable for me.

@caro: It is normal because it is part of the concept. If there’s no frame limiter the application will calculate frames as fast as possible. Run the square test and look at the frame counter. It should be somewhere around several thousands. This is what your cpu is doing and this is okay because every 3D game out there works this way.

Setting a 90 fps limit is pretty sensible. It stops you thrashing peoples computers creating frames that are never rendered since nearly all monitor refreshes at 60hz or so.

<cite>@zarch said:</cite> Setting a 90 fps limit is pretty sensible. It stops you thrashing peoples computers creating frames that are never rendered since nearly all monitor refreshes at 60hz or so.

Or set vsync on and never render an extra frame or tear a frame… because it will sync to the display.

True, however (with the default settings panel) vsync is a user config option. The FPS limit is not, so setting it to 90 means that no (likely) real frame rate will be limited while not thrashing with un-needed framerates.

<cite>@zarch said:</cite> True, however (with the default settings panel) vsync is a user config option. The FPS limit is not, so setting it to 90 means that no (likely) real frame rate will be limited while not thrashing with un-needed framerates.

Well, if you are going to arbitrarily set a frame limit then you might as well use an even multiple of the typical frame rate to avoid jitter. So 120 would probably better.

Except that 65 and 70 are common framerates too. You can’t be an even multiple of all of them without first reading the screen settings and then picking an appropriate number.

90 is high enough that we will get at least one frame rendered for every screen refresh no matter what. In fact I’m inclined to think you would might get more jitter.

I don’t think it’s a big deal anyway - you should set the limiter to something to avoid melting peoples computers (starcraft meltdown style) but as long as it gives you enough headroom over the frame rate it seems to look fine.

<cite>@zarch said:</cite> Except that 65 and 70 are common framerates too. You can't be an even multiple of all of them without first reading the screen settings and then picking an appropriate number.

90 is high enough that we will get at least one frame rendered for every screen refresh no matter what. In fact I’m inclined to think you would might get more jitter.

I don’t think it’s a big deal anyway - you should set the limiter to something to avoid melting peoples computers (starcraft meltdown style) but as long as it gives you enough headroom over the frame rate it seems to look fine.

You could also force vsync.

Non-even multiples have the problem that some visual frames represent one frame and some represent two. It 90 limit at 60 hz, every other frame (assuming even spacing) represents two frames… it can look pretty jerky. Well, jerky as compared to the alternative. You may not notice the jerkiness but you would certainly notice that 60 would be smoother.

1 Like

Except that would depend on timing. More likely the ratio would be closer than 1-2 since the refresh won’t exactly fall on any of the 3 but instead somewhere in between them.

I guess you could set it to 120 to be safer but honestly I’ve been running jme with it set to 90 for a long time now and not seen any jitter difference between limited, unlimited and vsync.

Of course people should try all 3 options for their specific game and get a couple of people to look at them to be sure.

Ok, I tried to reduce FPS in sample project and in my simple game and it works. CPU usage is about 30-40% (in game, in sample project is about 15%) when I set it to 90. But this is really strange for me cause on Ubuntu I don’t have to reduce frame rate and it works preety nice (process uses 5-10% of CPU). Maybe linux automatically reduce frame rate and don’t allow to exceed treshold of CPU usage. Anyway, problem was solved. Thank you very much!

It might be related to
http://hub.jmonkeyengine.org/forum/topic/performance-impact-of-glcheckframebufferstatusextgl_framebuffer_ext/