Recent

Author Topic: [SOLVED] BackTraceStrFunc slow in Laz 2.2.0/FPC 3.2.2  (Read 3146 times)

Mimmo

  • New Member
  • *
  • Posts: 15
[SOLVED] BackTraceStrFunc slow in Laz 2.2.0/FPC 3.2.2
« on: January 11, 2022, 09:04:42 am »
Hello,
working on the new Lazarus 2.2.0 and FPC 3.2.2 I've found that the execution of the BackTraceStrFunc function is really slower than with previous FPC 3.0.4.
In my tests, changes to optimization option, debugger (lazDebugger - GDB) and debug information types seem not to affect the performance.
Moreover I've found that:
* first time an exception is raised and traced -> BackTraceStrFunc is really slow
* every subsequent exception raised and traced -> BackTraceStrFunc returns to be as fast as with FPC 3.0.4
Any idea?
TIA,
Domenico
« Last Edit: January 11, 2022, 06:36:22 pm by Mimmo »

ccrause

  • Hero Member
  • *****
  • Posts: 568
Re: BackTraceStrFunc slow in Laz 2.2.0/FPC 3.2.2
« Reply #1 on: January 11, 2022, 10:07:40 am »
Do you mean that BackTraceStrFunc itself is slow, or that stepping into or over BackTraceStrFunc calls during debugging in Lazarus is slow?

If the latter, try using fpdebug (package LazDebuggerFp) in place of gdb.  Fpdebug is noticable faster than gdb when debugging in Lazarus.

Mimmo

  • New Member
  • *
  • Posts: 15
Re: BackTraceStrFunc slow in Laz 2.2.0/FPC 3.2.2
« Reply #2 on: January 11, 2022, 10:48:46 am »
Do you mean that BackTraceStrFunc itself is slow, or that stepping into or over BackTraceStrFunc calls during debugging in Lazarus is slow?

The BackTraceStrFunc itself is slow, both during debug and when a compiled application is executed.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 9979
  • FPC developer.
Re: BackTraceStrFunc slow in Laz 2.2.0/FPC 3.2.2
« Reply #3 on: January 11, 2022, 12:06:30 pm »
(backtraces depend on binary format, so it could be good to mention your OS)

Mimmo

  • New Member
  • *
  • Posts: 15
Re: BackTraceStrFunc slow in Laz 2.2.0/FPC 3.2.2
« Reply #4 on: January 11, 2022, 01:10:51 pm »
(backtraces depend on binary format, so it could be good to mention your OS)

Sure, sorry! It's windows 10 64 bit. I'm going to perform the same tests on Linux (Xubuntu) too.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 7865
  • Debugger - SynEdit - and more
    • wiki
Re: BackTraceStrFunc slow in Laz 2.2.0/FPC 3.2.2
« Reply #5 on: January 11, 2022, 01:30:20 pm »
Do you mean that BackTraceStrFunc itself is slow, or that stepping into or over BackTraceStrFunc calls during debugging in Lazarus is slow?

The BackTraceStrFunc itself is slow, both during debug and when a compiled application is executed.

Yes, this (i.e.: that it is slow / not that it is slower than in older versions) is known.

One of the use-cases for the backtrace BackTraceStrFunc is to be called after a crash.
After a crash "nothing can be trusted". Meaning:
- the application can be in any state
- the memory or stack my be corrupted (I.e. data may have been written to memory via a dangling pointers. Important parts of the stack, mem-manager-structures may be destroyed)
With this in mind, any further code that is executed (including the BackTraceStrFunc) may crash again.
The BackTraceStrFunc  has been written to minimize the chance of such further crashes. But that means a lot of limitation, and that does have a severe effect on the speed.

I don't know why it is slower now, than before.

I don't know what OS and what bitness (32/64) you use?
Afaik for some targets, the default debug format changed (at some point, not sure if between 3.0.4 and 3.2.2) from stab to dwarf. (For some targets, stabs in no longer supported, so you may not even be able to force it).
Maybe the dwarf version of BackTraceStrFunc is slower.


Depending what you try to do, there are other ways.

If you need traces yourself, running on your own machine:
You can use the debugger, you can:
- set a breakpoint, and edit its properties
  Property "break" = false
  Property "snapshot" = true

You can then open menu: View > Debug Windows > History
There you will find an entry for each time the breakpoint was passed.
By default the top 5 frames are collected. But if you have the Stack window open, the stack window is set to 10 or more frames, then they will all be collected.

This will be faster than BackTraceStrFunc, but still a slow down.
To minimize the slow down, delete all watches from the watches window. (Watches are also collected for the history snapshots).

Ensure you use FpDebug, which is faster than GDB. (Well if you are on Mac, then its LLDB-based (FpDebug+LLDB) and that can't be changed).

You can further use breakpoints in the calling code to enable/disable the "snapshot breakpoint".
Thus only taking snapshots, if the function was called from certain functions (or not called from certain functions)
Search the wiki for "breakpoint properties"



If you ship this in your release, so clients can send back traces...
(Well you can try this local on your machine too)

- Compile the EXE with debug info (ideally not "external debug info")
- Copy the compiled exe
- use "strip.exe" (on Linux, just "strip") on one of the 2 exes.
=> So now you should have
  -  MyApp.exe -> after "strip MyApp.exe"
  -  MyApp-Copy.exe -> that was not stripped. (So still with debug info)
  Important is that both files are from the same compilation-run. The same invocation of "fpc MyApp.pas".

Now if you run   MyApp.exe  (the stripped/small one, without debug info) you will get backtraces, that are address only. No filename or lines.
But the traces should be a bit faster (still take some time)

You can copy and paste this trace into: menu View > Leaks and traces
And the press "resolve" and select the MyApp-copy.exe (with debug info).
That should give you the filenames and lines.

Test it before shipping a release.
Mind the filenames/line-numbers are only correct if both files are from the same compilation-run.
 


While I wrote this you mentioned your OS.

Afaik Win64 is now dwarf only. Stabs no longer possible.
So maybe that is why it is slower now...

Or maybe bug fixes in BackTraceStrFunc




Mimmo

  • New Member
  • *
  • Posts: 15
Re: BackTraceStrFunc slow in Laz 2.2.0/FPC 3.2.2
« Reply #6 on: January 11, 2022, 06:35:54 pm »

Afaik Win64 is now dwarf only. Stabs no longer possible.
So maybe that is why it is slower now...

Or maybe bug fixes in BackTraceStrFunc

Thanks a lot Martin for the useful infos.
I've made a couple of tests on linux (xubuntu 20.04) and in linux the tracing is as fast as with fpc 3.0.4.
As everything is however working fine, I'll switch to Laz 2.2 and I'll add a hourglass cursor (or something similar) in the exception log tracing procedure of my gui applications to let the user know that he must wait.
Thanks!

 

TinyPortal © 2005-2018