Why does it thinks that the source file was modified?

MikiWatts

I'm profiling my application on a Point of Sale hardware, and do so by deploying a version on the hardware, profiling it, then copying the profiler results back to my dev machine and loading it there.

When I load the results in my dev machine, i get a warning message saying "This source file appears to have been modified since profiling was carried out".
I don't understand where that message is coming from, since I didn't change the source code between deploying to the POS and profiling it.

How does the profiler decides that ?

Also, I'm not sure if this is related, but while in most places in the source view i can drilldown, someplaces just won't let me drilldown. Could it be related to that that the profiler thinks that the file is different ?

MikiWatts

I also just noticed that the line times are off from the functions themselves... see attached image for example



Could it be because in the settings i have the "save source code" option enabled ?

MikiWatts

Ok, I think I found the problem, I was profiling the release build, and with the debug build it works just fine.

Andrew H

The 'file has been modified' warning is shown if the time of modification of the file is different to what it was when profiling was carried out. This is usually a reliable indicator but can also be flagged up if the results are taken between two machines with their own copy of the same source code. The warning is flagged up because if the profiler isn't saving source code along with the results then any modifications will make the line-level timings meaningless.

Line-level timings not lining up with the source code can be caused by a couple of problems: the most common is that the application that was profiled was compiled from a different version of the source code.

A less common cause can be that the C# compiler records different line positions from those used by our source control for some reason. Visual Studio usually warns about inconsistent line endings in situations where this can occur. We don't currently know about any situations which can cause this, though exotic unicode line endings or odd combinations of the ASCII \r and \n characters could potentially cause a conflict.

The occasional inability to drill down through a function can happen for a few reasons: this facility is implemented by inspecting the source code and comparing it to the generated call stacks. If the line-level data isn't matching up to the source code for any reason, it can be impossible to determine which function calls correspond to which line of code.

Interfaces, events, anonymous delegates, the yield operator and other C# features can result in functions being called at run-time that look very different to the way they are specified in the source code, which will make this feature fail to work.