Application slower when BDS not running

[Duoas]

Hi all.

I'm writing a little program that paints and animates its own form in response to the user's mouse gestures. The weird thing is:

Whenever the BDS Delphi 2006 is running and I run my application, I get a framerate of about 25 FPS. If I terminate BDS but not my application the framerate stays high.

However, if I then restart my application when BDS is not running my application runs at about 11 FPS. This is without any change to the code or executable. (This also seems to me to be a little backwards... alas.)

I've recompiled my app using Delphi 5 and it still gets the slow framerate. My only conclusion is that BDS is doing something to the system or loading some Borland/Codegear shared module that is bumping performance?

In short, does anyone know why this is happening? And where I should look to make my application get the higher framerate?

Thanks

[jsosnowski]

Have you compared the running processin the Control panel both ways?

[Duoas]

Hey, thanks for the reply.

No, I haven't used the control panel. I've directly timed it as: (number of paint events)/(milliseconds elapsed) while scrolling.

The point is that my executable is not modified in any way between testing with BDS running and testing without BDS running. Yet, my executable performs better when BDS is running.

Which means to me that BDS must be doing something either to the system or to the in-memory libraries common to both my application and BDS to make things faster. I can't figure out what that is though...

[jsosnowski]

I was thinking that the processes window i the Control Panel would give you a view of what else is running when BDS is. A comparison of process with and without BDS might give you a hint. Also, does your program run slow if BDS was running and then shut down, as opposed to having never run between start-ups/log-ons?

I was thinking that the processes window i the Control Panel would give you a view of what else is running when BDS is. A comparison of process with and without BDS might give you a hint.

I think that it's the best way to confirme if there is some diferente thing loaded by BSD.

I recommend Process Explorer v11.13, freeware from Microsoft.

Another point, like process priority - maybe BDS is (or put you program to) running with priority above normal.

Douas, you are using only a paint method? (nothing like DirectX, OpenGL... methods)

Bye

[Duoas]

Thanks for the info. That Process Explorer is slick.

Alas, I don't really know what I am looking for. As far as I can tell, my application and BDS don't share anything... (except some non-relocated kernel DLLS).

Other than that, all I know at this point is that my application runs more than twice as fast when BDS is in memory than when it is not.

The following behavior might be of interest:
1. Start BDS, then my app. Stop BDS. My app stays fast. Restart my app and it is slow again.

2. Start my app, then BDS. Stop BDS. My app becomes slow again.

3. BDS is always fast.

Arrgh!

The following behavior might be of interest:
1. Start BDS, then my app. Stop BDS. My app stays fast. Restart my app and it is slow again.

BDS load some thing; Your app uses it; BDS stop but this "thing" still is used by your app.
It sounds similar to a dll module load by an application...

2. Start my app, then BDS. Stop BDS. My app becomes slow again.

At this point, when BDS was started, your program was turned immediately fast? :icon_confused:

I had think about GDI and GDI+, but I can't found some logica explanation to this case.
All graphical functions declared on Windows unit made reference to the GDI32.DLL. The GDI+ (GDIPlus.DLL) improve GDI... maybe the BDS was load GDI+... but this make no sense.

Sorry don't help you more. Maybe jsosnowski has some an other sugestion.

Good luck.

[Duoas]

That's my thought exactly. I just can't figure out what BDS is doing... But I'll take a look at the GDI+.

I'm wondering if BDS is doing some sort of in-memory modification of one of the shared DLL's? (But that makes no sense either, because each process gets its own copy...) Is isn't overclocking my CPU or anything... aarrrrrghhhh.

I've also compiled with RtlVclOptimize.pas and I'm considering adding FastCode also...

[jsosnowski]

The only other though I have is ... We are assuming that something is turned on by BDS, what if something is being disabled that normally slows down the display rate?

[Duoas]

It is a possibility. It occurs to me that there might be something happening with the paging file or somesuch...

I wrote the program to operate off of a CD (via autoplay). I got the display rate sufficient to use, and the time came for me to give it to my friend (as a birthday gift), so I burnt it to CD and tested the CD, and the display rate went up to about 13 FPS.

Alas.

[grumbly_frown]

Did anyone get to the bottom of this?
I have a similar problem with BDS2006 C++ Builder - my first thoughts were that the TQuery Borland Database Engine was the problem but this thread leads me to believe that's a red herring?

Any ideas?

[Duoas]

I'm afraid not.

I've been running the DAEMON Tools Lite CD/DVD emulator and I noticed that it ran full-speed when running the ISO from the emulator.

My current "best guess" is that the IDE (and DT) causes the program to be loaded entirely into memory (no paging) and so it runs faster. But I have no proof of that.

Since my program currently runs with a high-enough framerate to avoid choppy animation I've not tried to figure this out entirely.

The code that does the drawing is double-buffered, and it essentially redraws about a fifth to a third of the display (depending on the user's resolution) each frame, by pasting a background image and then linking through some highly-optimized blitting operations for each scrolling icon.

Your problem has nothing to do with video update? It is a database query problem?

[grumbly_frown]

Indeed - no video stuff at all!

So -you're idea about memory paging is damn fine one I think and worth more investigation - which I'll try to do next week.

Many thanks!

I'm afraid not.

I've been running the DAEMON Tools Lite CD/DVD emulator and I noticed that it ran full-speed when running the ISO from the emulator.

My current "best guess" is that the IDE (and DT) causes the program to be loaded entirely into memory (no paging) and so it runs faster. But I have no proof of that.

Since my program currently runs with a high-enough framerate to avoid choppy animation I've not tried to figure this out entirely.

The code that does the drawing is double-buffered, and it essentially redraws about a fifth to a third of the display (depending on the user's resolution) each frame, by pasting a background image and then linking through some highly-optimized blitting operations for each scrolling icon.

Your problem has nothing to do with video update? It is a database query problem?

[cdrodriguez]

Hi, I am having same problem with an application not concerning video at all.
Have anybody manage to solve the problem?
Any idea where to continue investigatin?
Thank you very much.

[Duoas]

Unfortunately I never did have much time to sink into it, so I never did figure out what caused it. I still think it has to do with memory paging or something...

I just optimized the tar out of the code so it works fast enough to respond reasonably snappy... (The optimization was something of a design decision at the outset, so I didn't waste too much time with it.)

Sorry I just don't know right now.