Stellarium looses performance

[Frédéric Buclin]

On Mandriva Linux 2010.2, Stellarium 0.10.5 eats 100% of the CPU (fortunately, I have a dual core, and so other processes can use the 2nd CPU), even when left in the background (it also eats 325 Mb of virtual memory, but that's fine). This is by far too much. I guess it's still recalculating the position of each star, but this should probably be suspended till the application gets the focus again.

[Matthew Gates (matthew-porpoisehead)]

What FPS do you get? If it is less than 10 then I would think your system is using the CPU to render OpenGL... in this case you will see 100% CPU (OpenGL rendering on a CPU using mesa is _very_ heavy). To reduce this you must have video hardware and drivers which can move rendering load to the GPU. For some hardware this means using proprietary drivers, but not always. Some ATI cards can get hardware acceleration using the fglrx driver, and the "nouveau" driver can accelerate some nvidia cards.

Even with GPU acceleration for OpenGL rendering, Stellarium is still not a light-weight application. I get about 15% CPU use when Stellarium is running. You can set the maximum FPS in the ~/.stellarium/config.ini file which can cap the load (lots of things need calculating per frame, such as planet positions, so reducing the frame rate to 20 or something like that can help if you would like to have lower CPU load).

I hope that helps

Matthew

[Frédéric Buclin (lpsolit-deactivatedaccount)]

FPS varies, depending on what I'm doing. But it's around 100-200 FPS now that I restarted it, and CPU went down to 15% only. But before I restarted it, it was at 8 FPS, with CPU at 100%. I wonder why it did that. Maybe because it was running for 3 hours? Since I restarted Stellarium 4 minutes ago, CPU already increased to 19% (not sure how significant that is). Is there a way to track what it's doing?

[Frédéric Buclin (lpsolit-deactivatedaccount)]

Also, I don't see why this bug is invalid, per my previous comment.

[Frédéric Buclin (lpsolit-deactivatedaccount)]

OK, Stellarium is now eating 28%, and FPS decreased to 60-70 only. All this in a few minutes (since my previous message). So something wrong really happens. Not invalid, IMO.

[Matthew Gates (matthew-porpoisehead)]

FPS should not systematically drop over time, although it can vary for several reasons - mostly depending on what is displayed at the time. For example, day time sky rendering takes a different amount of time from night time sky rendering. Also, different zoom levels will create different FPS... and also simply how many objects are in the field of view.

To rule out these possibilities, please can you do the following (I myself am doing this right now to see if I can replicate a drop in FPS, but since your system apparently suffers from this a lot, it would be very helpful if you could check it too):

1. edit the ~/.stellarium/config.ini file and set both the minimum_fps and maximum_fps values to something very high (e.g. 10000). This will prevent the power saving mode kicking in and confusing things.

2. start Stellarium and then press the "j" key. Verify that simulation time is now frozen.

3. wait for your system to settle, and note the fps. Please do this scientifically - verify no other apps are running, and then take several measurements of the FPS and average them.

4. leave Stellarium running for as long as you did before when you found the problem (several hours). Go about your other business. Do not alter Stellarium's state in any way - no zooming, no changing what things are displayed and so on.

5. Come back, make sure all other apps are closed and measure the FPS again.

Report back here. I'm going to do so after a couple of hours. My average FPS is 90 at the start of my experiment.

P.S. Regarding the invalid status - we get a very high number of problems caused by bad video drivers. My suspicion was that you simply didn't have accelerated OpenGL drivers running on your machine, hence the status (since that is a pre-requisite of running the app). Now it is clear from your initial 200 fps that this is not the case, the status can be changed. Please do not change the status yourself - it is for developers to decide if a bug is real or not, according to the information provided. I have not confirmed that there is a bug in Stellarium at this time. Confirmed is not appropriate unless someone else can replicate your problem.

[Matthew Gates (matthew-porpoisehead)]

No drop in FPS yet... wondering what plugins you have enabled...

[Frédéric Buclin (lpsolit-deactivatedaccount)]

I left Stellarium opened for two hours, freezing the time as suggested in comment 5 step 2, and noticed no increase of the CPU. It was consistently at 8-9% during these two hours. The FPS was at 18. So the CPU usage increase has something to do with zooming or time acceleration, probably. I will do some tests and see which action triggers the CPU usage increase.

(About the "confirmed" status, that was the only sensible one available when leaving "invalid". "new" was not selectable, else I would have selected this one.)

[Frédéric Buclin (lpsolit-deactivatedaccount)]

OK, I found a way to reproduce the problem. Leave the time frozen as you suggested, click on Jupiter, which was in my FOV, press the Space keystroke to center on it. Press the "Page Up" keystroke to zoom on Jupiter till its main satellites are visible (FOV = 0.15°). Wait several tens of minutes. Instead of 8%, Stellarium now takes 27% of the CPU after ~40 minutes, and it's still increasing. The FPS is constant at 18.

[Ross (rosario-ing)]

I faced this issue too, without solving it. I have Windows 7 64 bit H.Ed. and a Zotec GeForce GTX 460 video card on a Core i5 system (but it occurs also in a Windows Vista system with a Radeon ATI video card and Pentium 4).

This issue sometimes rises and sometimes not, I don't understand when it happens and I'm not able to reproduce it sistematically. It seems it occurs randomly, but I think it's related to the setFlagTracking() and the wait() script functions.

It occurs suddenly. The same script sometimes generates the problem and sometimes not, so I'm not sure it's related to the script itself.

No other apps are running, no antivirus. The minFps and maxFps are set to 10000 in the config.ini file, without success. I also changed the power-saving mode of my system setting it to the best performance, but nothing happens.

The bug: suddenly, motion is no more fluent as it started and Stellarium performance degrades and motion becomes choppy (not very much, but it bothers). The only thing to do is quit&restart the program. I noticed that if you wait for the system to go in power-save mode, and then come back, performance seems to raise.

Bug seems more frequent if you use the zoom functions or PageUp/Page Down buttons, but I think is not related to them.

During choppy, CPU levels decreases a bit, but nothing you can do to set it to a higher level. I also used a Windows utility to set the minimum CPU level to 20%, without success. At first I thought it was related to the configuration of my PC, but it occurs in all of my PCs (sometimes you have to wait tens of minutes).

I use Stellarium 0.11.0 on a 64-bit environment. The bug is also in the 0.10.6.x versions.

I don't know if it's useful: I make heavy use of scripts.

[Ross (rosario-ing)]

Ok, in my case, CPU level never reaches 100% usage. Perhaps the correct topics is "Stellarium looses performance"

[Fabien Chéreau (xalioth)]

Maybe it's caused by a memory leak or something like that. Did you also check the memory usage in time when this happens?
Fabien

[john duncan (banner001)]

i have the same problem. I have noticed that when i zoom in, in the bottom right corner a grey window apears saying "loading nebulae" that seems to cause the frame rate to drop. for me, my 100% cpu bug is when i enable occulars, 10% of the time the problem does not appear, but if i go to "next occular" the screen will go white (where the view normally is) and the cpu will be running at 100%. sometimes going back and forwards through the occulars solves it, sometimes not.

also when stellarium is running normally (i.e. not at 100% cpu, turning windows media player on will cause stellarium to jump to 100% cpu and will cause media player to stutter.

[Ross (rosario-ing)]

Ok, finally (I hope) I found what the problem is...

Try this code (on a Windows 7 64bit system, like mine):

core.selectObjectByName("Sun",false);
StelMovementMgr.setFlagTracking(true);
StelMovementMgr.zoomTo(1,8);
core.wait(8);

or this one:

core.selectObjectByName("Sun",false);
StelMovementMgr.setFlagTracking(true);
core.wait(2);

It becomes choppy (or jerky, I don't know the exact term, but if you try the code, you can understand... ;-) ). It seems it rises when you use in combination:
 * tracking (on)
 * during a zoom or while the tracking is centering the object selected
 * using core.wait()

If you delete the core.wait(8) line, problem disappears almost completly, but sometimes you have to use it like a "sleep" function and you can not do without it.

CPU, level memory and frames don't change enough to explain the problem. In my config.ini file, the "maximum_fps" parameter is set to 10000. Don't know if the problem affects also Linux systems or older versions of Windows.

[Keatah (keatah)]

I thought I test this out per post #8. I left my old xp sp3 machine running it for a whole week and weekend straight. No increase in cpu or memory usage.

[gzotti (georg-zotti)]

This is a report from 0.10.5! Is it really still open?

[Frédéric Buclin (lpsolit-deactivatedaccount)]

I can no longer reproduce the problem with Stellarium 0.12.2 on Mageia 4. The CPU remains constant at around 20%. No idea if the problem has been fixed or upgrading my OS did the trick.

[gzotti (georg-zotti)]

Thanks for reporting back. I think we can close this and consider it fixed by developments in the last 3 years :-)