Recent

Author Topic: Debugging in lazarus causing stutter even when no debuffer features are in use  (Read 2639 times)

JernejL

  • Jr. Member
  • **
  • Posts: 92
I'm developing a game with lazarus, and for a while i was trying to figure out what was causing random stutter / lockus in my game when testing.
 
At one point i was doing something and ran it without debugger directly, to my surprise the game ran absolutely perfectly smooth.
 
My understanding is that GDB or lazarus debugging somehow causes this, it is really obvious to reproduce.
 
I have no idea if this could somehow be solved, is this somehow by design, could i configuire something?
 

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9794
  • Debugger - SynEdit - and more
    • wiki
When a debugger attaches itself to a process, it uses the API of the OS. I guess in your case windows.

With that, the OS starts informing the debugger of certain events: library load/unload, fork, thread create/destroy, ....
I am not sure, but I believe each of those notifications cause a tiny pause to the debugged app.
I do not know, if the fact that gdb has to communicate those to the IDE will make a difference to the length of the delay (if any).

Also if the app uses exceptions, that will cause slowdown. Even if the exception is ignored. Every exception means that the app will be paused, and the exception be inspected (by the IDE), and then the app gets continued.

There may be other things that I am not aware of. (I do not know gdb internals).

Things you can try:

A newer gdb version. For Windows check our SourceForge site (downloads) in the Windows 32/64 folders you find "Alternative GDB". Try 8.2

In menu Tools > Option
Then Debugger > General (or in Lazarus trunk Debugger > Backend)
In the property list:
- DisableLoadSymbolsForLibraries => True (if your code keeps loading libs)

Trunk only (same property list):
- InternalExcepionBreakPoints: disable all 3 of them.
This will disable all fpc exception handling. All exceptions to be ignored (it is faster than ignoring individual ones)


On Windows/Linux you can also install the package LazDebuggerFp, and change your debugger to "fpDebug" (tools > options > dbg)

This debugger does not use gdb at all, and therefore does not loose time talking to an external exe via pipes.
It still gets all the events from the OS.

FpDebug is very new, and still undergoes testing. In 2.0.8 it has a few known minor hickups. 
I am using it in trunk (testing it) and it seems fairly ok.
« Last Edit: May 01, 2020, 06:26:03 pm by Martin_fr »

JernejL

  • Jr. Member
  • **
  • Posts: 92
To my knowledge my game should not be generating any kind of internal exceptions - All the code is written in such a way that if one does occur it is a fatal exception, it will not have any kind of exceptions except if you don't have 500mb of free ram or mess up the files.
 
There is also nothing outputted in event log or debug output at time of stutter.
 
i will try to use LazDebuggerFp, and see how that works.
 

Thaddy

  • Hero Member
  • *****
  • Posts: 14215
  • Probably until I exterminate Putin.
To my knowledge my game should not be generating any kind of internal exceptions - All the code is written in such a way that if one does occur it is a fatal exception, it will not have any kind of exceptions except if you don't have 500mb of free ram or mess up the files.
 
There is also nothing outputted in event log or debug output at time of stutter.
 
i will try to use LazDebuggerFp, and see how that works.
To be able to debug, you need to compile with debug information. This can also be an external debug file.
Your production code should be compiled after debugging and without debug information.
It is ready when it is ready.
Specialize a type, not a var.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9794
  • Debugger - SynEdit - and more
    • wiki
@Thaddy: I do not think his problems happened while he tried to debug. But rather because "F9/Run" starts the project in the debugger, even if you do not want to debug.

So debug info is not his problem.
Debug info would also (except for initial load time / load time of dll) not affect the speed at which the app runs.

@JernejL:
One point to consider after Thaddy's post. When you run without debugger, you just used the "run without debugger" from the run menu, or you started the app outside the IDE?

You did not change any other Options? You did not change build-mode, assertions,  run time checks (overflow/range/...), optimization, ...?


In case of interest, here is what Windows reports to the debugger https://docs.microsoft.com/en-gb/windows/win32/api/minwinbase/ns-minwinbase-debug_event
Each time one of those events happens, your app is paused for a very short time.
The event log may be filtered, and not show all of them (see options).

Using GDB, you can look at menu View > Ide internals > debug output
(depending on Lazarus version, this may be View > Debug windows > debug output)
And you will see whatever gdb reports. Yet gdb may get events that it does not report.

Anyway that would not resolve the Issue.


JernejL

  • Jr. Member
  • **
  • Posts: 92
The app is built with all debug symbols and all possible options, variant debug symbol is stabs.
 
If i run this with debugger it stutters, if i run same exe standalone (outside ide) it runs smooth.
 

JernejL

  • Jr. Member
  • **
  • Posts: 92
Well finally i have some development, on internet i found a copy of fastmm4 that actually works with freepascal: https://github.com/maximmasiutin/FastMM4-AVX
 
I decided to try it with my game i'm writing in freepascal, and behold! After i use that, there is no more stuttering when running with debugger at all.
 
The whole game also loads noticably faster, i guess original freepascal memory manager is totally unsuited for games.
 

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9794
  • Debugger - SynEdit - and more
    • wiki
i guess original freepascal memory manager is totally unsuited for games.

What can cause a noticeable slow down is using -gh (heaptrc).

JernejL

  • Jr. Member
  • **
  • Posts: 92
i guess original freepascal memory manager is totally unsuited for games.

What can cause a noticeable slow down is using -gh (heaptrc).

 
That wasn't used, because a compiler bug prevented me from using it: https://forum.lazarus.freepascal.org/index.php/topic,38404.msg362837.html#msg362837
 
A strange behavior is, this only happened when debugger was running.
As for fastmm4, it runs faster regardless if i am debugging or not.
 

 

TinyPortal © 2005-2018