Back to Questions
756
views3
comments
A strange performance problem...
f#

Hello,

I've just ported an F# solution to the VS 2010 release candidate. I'm now experiencing a very weird issue.

My solution produces a console application as the final output. If I compile this solution under the normal "Release" settings (i.e. with optimization turned on), the resulting executable completes a benchmark test in approximately 50 seconds. If I launch the profiling wizard and then have VS2010 run my program under the "Instrumentation" option, the benchmark test finishes in about 5 seconds. I find this behaviour confusing.

Has anyone else experienced this? I know it sounds stupid, but I've consistently reproduced this behaviour.

Finally, I've searched through VS 2010 for some place where I may have forgotten to turn on an optimization flag. I can't find such a place. Am I missing something?

Best regards,
--
Grendel

.

That does sound fishy! Brainstorming...

(Have to ask: is the benchmark CPU bound? E.g. not talking to a web service that may have slow connection, or anything else silly like that. And I guess you're just running with "Start without Debugging" (Ctrl-F5) in the non-instrumented case?)

A rare possibility may be tail call performance. You might try unchecking 'Generate tail calls' on the Build tab of the project's Properties, and see if that affects the Release mode performance. I can imagine that an instrumentation pass might remove tail calls as part of its IL rewriting.

What is the performance difference between "Debug" and "Release" (both uninstrumented)?

By on 2/19/2010 3:00 PM ()

Thanks for the reply Brian.

It turns out that I am, in fact, an idiot. I was hitting F5 instead of (Ctrl-F5) and, of course, the release configuration was set to optimize code whereas the debug configuration was not.

I am curious, however, about your suggestion that tail calls might cause a performance problem. I'm not using tail calls in my current project, but part of the appeal of F# (to me) is that its compiler will perform tail call optimization. Under what scenarios would this be a bad thing?

Thanks again.

By on 2/20/2010 9:27 AM ()

I am curious, however, about your suggestion that tail calls might cause a performance problem. I'm not using tail calls in my current project, but part of the appeal of F# (to me) is that its compiler will perform tail call optimization. Under what scenarios would this be a bad thing?

You can see e.g.

[link:connect.microsoft.com]

I don't recall all the details, but e.g. maybe on x86 CLR 2.0, given certain sets of function parameters, the CLR implementation had to use some non-JITted helper to make the tail-call happen, and in edge case scenarios this would show up in the overall app's perf. I think CLR 4.0 is now much better at perf here, as well as honoring the .tail IL instruction in general - the CLR team did some great work here for 4.0.

By on 2/20/2010 10:02 AM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper