Get stack trace quickly

[ExceptionHandling]

I am searching for a more performant way to get the current stack trace. The tracing needs to be done in a central method deep in the code, which is necessary to determine specific code lines for restructuring.

So far I used the function MadExcept.CreateBugReport to return a stack trace, but this function takes up to 800 milliseconds per method call. Then I tried to use the function MadStackTrace.Stacktrace, which takes up to 40-45 milliseconds, but still takes too long.

Is there a way to get the current stack track more quickly? Maybe the stack trace can be shortened or something like that?

[madshi]

Do you always need the stack trace? Or do you just want to store it, and then maybe you will need it later? If you only need it sometimes, there's a way to store the necessary information for a stack trace very quickly, and then only do the actual processing in case you need it, at a later point in time.

If you always need it, you could set the StackTrace's "dumbTrace" parameter to true, which should bring a nice performance boost, on the cost of having more "noise" (invalid stack items) in the trace.

[ExceptionHandling]

I need to determine 2 stack traces, whereas the 1st trace is temporarily stored in a variable for later purpose. When specific conditions in the code apply, a 2nd stack trace is also determined, then both stack traces will be logged in a database.

I will try to use this dumb trace parameter.

[ExceptionHandling]

When setting the parameter to True the performance doesn't really seem to have improved. For testing I used the function MadStackTrace.StackTrace with default settings, but with the suggested parameter set to true. The stack trace determination still takes up to 40-45 milliseconds.

[madshi]

Are we talking about a 32bit or 64bit EXE? In 64bit I suppose performance might not benefit, but I expected there to be a difference at least in 32bit.

Anyway, I fear I don't really have a stack trace method which outputs a valid stack trace but is optimized for highest performance. I do have 2 variants: 1) Slow and good quality. Or 2) just store the information, and do the processing later. For madExcept's own purposes it's all that's needed. I don't really need a fast method which still outputs a "full" stack trace string, so I didn't really spend time on developing such a function.

[egnsb]

This is exactly what I am looking for right now.

How do I store the necessary information for a stack trace, and then parse the information from it when I am ready?

[madshi]

That sounds like a completely different topic, though? You basically want to store the needed information and maybe do the stack tracing later, at a suitable time. Isn't that correct?

"madStackTrace.pas" exports a function called "PrepareStackTrace()" which will output an "AnsiString". This is done very quickly. Later, when you actually want madExcept to do the full stack trace processing, you can pass this AnsiString to the madStackTrace.StackTrace() function, see "preparedStack: AnsiString" parameter. This whole logic is used quite often in "madExcept.pas", so you can check the "madExcept.pas" source code to see how it works in detail.

[egnsb]

I thought it was the same topic: How to get the stack trace quickly.
To me, "stack trace" is the necessary bits, and the parsed info is just converting it to a different form. But maybe it means something different to others.

Thank you, that is helpful. I think PrepareStackTrace will work for me. However it is not as fast as I had hoped. I tested the performance, and found that 95% of the time is taken by calls to VirtualQuery() in StartTryRead. Would it be possible to cache or minimize that information somehow?

[madshi]

I can add that to my to do list, but I won't have time to look into this any time soon. Busy with other stuff atm, and it doesn't seem like a critical problem for most madExcept users.

[egnsb]

That sounds great. However, to be honest, that particular improvement would be useful for me right now, but I will add a filter to reduce the number of times I call PrepareStackTrace, and probably I'll never need the same kind of thing ever again.