Big CPU Problem in compiled EXE

[Walter Sommerfeld]

Hi,

yesterday i noticed a big drawback in an generated EXE of my original FS 1.15 pro project:

Even wo any ruby or blue component a Bitmap Background raises the CPU use in my original project EXE >2000% (yes 3 Zeros)

2 test this behaviour just compile and switch the Big On/Off Button!

btw: Tested it again in v1.15... same probs there
...my Quad Core shows this effect even more than my older Core Duo

[nix]

it goes from 2%(off) to 10%(on) here on my weedy laptop Walter.
Just trying to see what is happening in the schematic

[MyCo]

CPU difference here is only 1-2%, I use an old quad core Q6600

[trogluddite]

My guess - the bitmap is a different size to the output area, and so is being scaled by GDI+ (i.e. using the main CPU). The interpolation of the bitmap is possibly being done for every single redraw of the overlaid meters, and probably for the whole of the bitmap - which will be a pretty CPU intensive task for an 800*600px bitmap at 25fps.
The huge differences between our readings could be explained by several things - but available CPU cache space would be my best guess - the CPU cycles will skyrocket the more that pixels need reading/writing to the main memory.

Even inside FS, if I change the source area to be 'ViewArea->Grid_to_pixels' (i.e. take an unscaled section of the bitmap), the CPU load drops from >50% to <15% (intel Atom!)

I have noticed a similar effect before with SM exe's if you use the full screen + zoom modes. Always best to make your bitmaps at the size you intend to use them.

[Walter Sommerfeld]

Hi guys,

I have noticed a similar effect before with SM exe's if you use the full screen + zoom modes. Always best to make your bitmaps at the size you intend to use them.

Well i've cooled down now...

I just dropped that biiigg Background from my toolbox wo worrying about the size... my fault - but i hoped FS fixes this in the compilation process - Silly me!

Hope the Devs can give a comment 2!

cu

[support]

Interesting - the cpu hit here is negligible and changes very little between switching. This is on a 2.7GHz core i5 - not the fastest but not the slowest either.

As trogluddite points out, the bitmap is overlapping with the redraw area and so it gets processed each time. So it's best to have bitmaps made to the correct size and not have them rescaled in the schematic.

[Walter Sommerfeld]

I hoped again with this update i can reduce the CPU use of my projects...

and again have to change many things (trigger behave etc.)
and also tried to get ruby into my old brain:

Now i tested this on my oldie Core Duo and Quads (btw. not every user owns an i7)
FS v1.15 vs FS3:
Even the ruby Level meters halves the comps and Private bytes amount it uses triple CPU power on the Duo and approximate the half of that on the quad (...all w/o the background probs mentioned above)
And the exe is 3.3 MB instead of 1.7 MB in size (ruby overhead - i know...)

[support]

Walter, if you email us the two files you're comparing for cpu or post them here we can take a look. You shouldn't be getting any higher cpu in FS3 than you had with FS1.

[Walter Sommerfeld]

Thanks 4 ur offer... but:

Back 2 the roots...
Even if my discrete Levelmeters (separate Module for every LED) uses more comps they are my own dev and
very optimized with the help of Trog...
So please try 2 optimize the GDI+ routines or better replace them with a GPU assisted one...
Ruby makes here no difference!

Walter

[trogluddite]

Well, I have my own doubts about GDI+ too, but I would point out a couple of things...

- I did not use earlier versions of FS, but you say you see a big extra overhead in FS3 compared to earlier versions. If you are on the same machine, and same Windows, then GDI+ has not changed - therefore there may be some changes in FS that make this difference -so I would still advise to share the schematics with the dev's. It may be key to some GDI+ optimisation like you ask for.

-

they are my own dev and very optimized

But relying on native re-scaling of the bitmap is not "very optimised" within your development environment of choice. The wise developer does not rely on a djinn to grant his wishes - either a different tool must be chosen, or the best possible compromise made with what is available...
- Use the most appropriate input data (i.e. a correctly dimensioned bitmap)
- Use a more efficient process (i.e. crop instead of re-scale the bitmap)
- Perform the intensive process offline (i.e.use other bitmap primitives to rescale the image within the schematic.)
None of these may seem "ideal" to you, but nobody has yet invented an "ideal" programming language or modular environment - so there is a trade between simplicity/familiarity/availability, and the difficulty of learning a new tool.

But 3D texture-mapped robots using OpenGL, Hmmmm....