Poor performance of madExcept under x64?

[madshi]

I'm quite relieved to hear that it's not a bug in madExcept. Problems like these can be extremely hard to fix, and it's especially bad if the problem is my fault - but does not occur on my PC. So I was really afraid this could end up being a pain to solve. So I'm happy that it's my fault after all.

So I guess the madExcept x64 stacktracing modification I did gets the green light? I could release a new official build this weekend then.

[davidheffernan]

Yeah, I'm happy with the new 64 bit stack tracing code. I've managed to work out what the issue is. And it's a rather dreadful bug in the RTL.

1. InternalTextToFloat calls GetMXCSR/SetMXCSR to save, change and then restore the FP control state.
2. SetMXCSR copies input parameter (the new state) into a global variable DefaultMXCSR and then loads DefaultMXCSR into the FP unit.
3. When you have multiple threads calling InternalTextToFloat at the same time there is a race on DefaultMXCSR.

That code really is a load of old rubbish and I'm going to use a code hook to fix it. Grr.

I look forward to being able to adopt the next official release with fast, high quality x64 stack tracing.

[madshi]

Ouch. Yeah, yet another bug in the RTL <sigh>.

[davidheffernan]

FYI, I came across the following rather interesting series of blog posts that includes some details of how RtlCaptureStackBackTrace is implemented: http://www.nynaeve.net/?p=101

[madshi]

Ok, now we know that RtlCaptureStackBackTrace does actually provide "perfect" callstacks. I was not sure about that until now. Anyway, the new solution I found is faster, isn't it? The problem with RtlCaptureStackBackTrace is that I can't delay it. I can only call it in the moment when the exception is raised. The solution I'm using now simply stores the stack contents and does the stack tracing later. So performance with *handled* exceptions should be better with the solution I'm using now. However, performance with *unhandled* exceptions would be better with RtlCaptureStackBackTrace. But I think that's less important...

[davidheffernan]

Yeah, I'm very happy with the performance of your stack contents capturing approach. As you say, for handled exceptions that simply has to be faster than reading the stack, and generating the back trace.

I just wanted to share some knowledge with you which may well turn out to be useful at some point in the future.

[madshi]

Yeah, it is useful, thanks.

[Fábio Lindemberg]

I have a performance problem in Window 2008 Server, My application freeze after press OK Button in an exception dialog box.
I debug and discovery the source code that freeze my application, this is: DispatchMessage(Msg). I saw this comment "// in win9x a call to DispatchMessageA results in a broken stack trace" and assumed that this line not apply at 64x platform, so I comment it and my problem was solved. but this is a temporally solutions, could you solve this problem?

[madshi]

Where is this "DispatchMessage(Msg)" line that is responsible for the freeze? Which pas file which function?

This "in win9x a call to DispatchMessageA results in a broken stack trace" comment is in a part of the source code which is not executed on 2008 Server (unless you're running your exe in win9x compatability mode!?).

[Fábio Lindemberg]

this .pas is madexcept.pas and the procedure is HandleException. In debug mode apparently is this line that freezes for a fill seconds everytime that dialog box is displayed!

how I said, after comment this line, the problem was solved!

[Fábio Lindemberg]

I did this modification in version 3.x, before I tryed update to new version 4.0.5 but the bug occurs too, so I back the version and tryed do this.

[madshi]

Hmmmmm... It does not seem to happen on my PC. Can you reproduce this problem with a brand new test project? If so, could you please send that test project to me? I need to be able to reproduce the problem on my PC, otherwise it's going to be hard to fix. Simply removing that DispatchMessage(Msg) line is not a good idea. Basically it will result in the main form of the crashing being "frozen" while the exception box is shown. So we need to find the real cause of the problem.

[jeckels]

I just wanted to weigh in on this, that we have one of our applications that is using exceptions almost exclusively to drive program flow. If swallowing exceptions is indeed a significant overhead, I will know it almost immediately


I just placed an order for the latest release of madExcept.

I am anxious to see how this performs once stack tracing is put in place.

Just FYI.

[madshi]

As long as you don't have thousands of silent exceptions per second, you should be fine. If you have any problems, just let me know.

[jeckels]

Just downloaded a copy, and tried while I wait for a download and license key from the purchase ....

I can see that with madExcept enabled it is roughly 5x slower.

Without madExcept
about 12 minutes

With madExcept
about 67 minutes

Yes, there are thousands of "handled" exceptions flowing. This is a x64 build.

Code: Select all

psuedo-code

whlie not eof do begin
    try
         // do lots of complex stuff, but ultimately the flow when OK raises an exception to indicate that, and inside of these sub-routines there is a similar apprach to using exceptions to control flow
    except
        on e: EAllIsOk do begin
            // nothing to do, completed that iteration successfullly
        end;
    end;

end;

For this one app, I am using PauseMadExcept; as a workaround so that particular area isn't overwhelming the exception hooks.

Is there an alternative means (aside from rewriting the program to not use exceptions as a means to control program flow) ?