0

When debugging a Firemonkey app (a bouncing ball), a minute or so into the ball moving around, this message begins to pour out to the EventLog:

Module Load: D3DCOMPILER_47.dll. No Debug Info. Base Address: $14D50000. Process bo.exe (13824) Thread Start: Thread ID: 14268. Process bo.exe (13824)

It makes the debugging mode nigh useless. This is a Delphi Architect Trial version, blank form Firemonkey app. I thought maybe it is due to it being a trial version.

I do see about three threads starting before this happens. I'm not consciously starting any threads but I assume one is for the user interface and one is...for the debugger? I dunno. Here's a representative sample:

Module Load: imagehlp.dll. No Debug Info. Base Address: $74A30000. Process bo.exe (19228)
Module Load: GPAPI.dll. No Debug Info. Base Address: $612D0000. Process bo.exe (19228)
Module Load: CRYPTNET.dll. No Debug Info. Base Address: $60900000. Process bo.exe (19228)
Module Load: IPHLPAPI.DLL. No Debug Info. Base Address: $739B0000. Process bo.exe (19228)
Module Load: WINNSI.DLL. No Debug Info. Base Address: $72B40000. Process bo.exe (19228)
Module Load: NSI.dll. No Debug Info. Base Address: $74940000. Process bo.exe (19228)
Module Load: ltc_game32.dll. No Debug Info. Base Address: $11D60000. Process bo.exe (19228)
Thread Start: Thread ID: 16400. Process bo.exe (19228)
Thread Start: Thread ID: 19268. Process bo.exe (19228)
Thread Start: Thread ID: 18640. Process bo.exe (19228)
Thread Exit: Thread ID: 16400. Process bo.exe (19228)
Thread Start: Thread ID: 6096. Process bo.exe (19228)
Module Load: D3DCOMPILER_47.dll. No Debug Info. Base Address: $14510000. Process bo.exe (19228)
Module Unload: D3DCOMPILER_47.dll. Process bo.exe (19228)

And the last two lines will be repeated ad infinitum.

UPDATE #1 (edited): I'm not trying to debug D3DCompiler. I am trying to locate the cause of the slowdown.

UPDATE #2: I turned off the debugger messages for modules and this did not help. At the same approximate point, the speed of the app drops precipitously. This only happens while debugging.

UPDATE #3: How to recreate:

  1. Start a new Multi-Device Application.
  2. Select Blank Application.
  3. Drop a TTimer.
  4. Drop a TRectangle.
  5. Add a boolean public variable "up".

  6. For Timer1Timer add the following code:

    procedure TForm1.Timer1Timer(Sender: TObject); begin if up then my := -1 else my := 1; if (Rectangle1.Position.Y + my < 10) or (Rectangle1.Position.Y + my > 470) then up := not up else Rectangle1.Position.Y := Rectangle1.Position.Y + my; end;

Set the TTimer Interval to something low. On my machine I can produce the effect with an interval up to about 60. This is as small as I've been able to make it while still getting the aforementioned debugger grind-down.

user3810626
  • 6,798
  • 3
  • 14
  • 19
  • Those messages are all related to Windows system DLLs. They are not shipped with debug info in them. You can get the debug symbols from MS, but they won't do you much good. Why do you think you need to debug system DLLs? Any issue is going to be in your own code. And how does output in the messages window about system DLLs not having debug info make debugging useless? Again, it's your own code you should be debugging, and not that of system code. – Ken White Sep 19 '16 at 02:49
  • I hope the edit clarifies. – user3810626 Sep 19 '16 at 02:57
  • So turn off the messages you don't want to see. Tools->Options->Debugger Options->Event Log. – Ken White Sep 19 '16 at 02:58
  • Thank you. Did that. The app still shows signs of some kind of churn. As noted, this does not happen while doing a run-without-debugging or when deployed. – user3810626 Sep 19 '16 at 03:08
  • It's unclear what you're asking. First it was the messages. Now it's *some kind of churn*. You do understand that debugging isn't going to be as performant as non-debugging, right? Because the debugger imposes some overhead and sets up things in order to keep track of where you're at in case it needs to stop or backtrack? It's not clear what specific issue you think you're having, because it seems like it's changing. – Ken White Sep 19 '16 at 03:17
  • My problem has not changed: My app suddenly slows down (debug mode only). I took your first message to indicate that it might be caused by the event log itself, and so turned off the messages. This did not help. Hence, I believe the slowdown may be due to the load/unload churn indicated by the messages in the Event Log. But of course, if I knew what the cause of the problem was, I wouldn't have to ask. – user3810626 Sep 19 '16 at 03:30
  • 1
    You need to show your app code. We can't guess what you are doing. This type of thing can be for all sorts of reasons, for example, a multiple (recursive) trapped exceptions, running out of memory due to leakage (which will happen faster while debugging because you have less memory available) etc., etc. – Dsm Sep 19 '16 at 07:53

1 Answers1

2

So, Firemonkey guru Eli M on the Embarcadero board, gave me the answer to this, which I post here for future folk:

FMX.Types.GlobalUseGPUCanvas := True;

Simple as that.

N.B. this has other side-effects: In my case, I had been using fonts with default size specifications which scaled fine when this was false, and got ultra-blurry when this was true. (I just made the fonts bigger but I'm sure that's not the only effect of setting this.)

user3810626
  • 6,798
  • 3
  • 14
  • 19