Comments
Sort by recent activity
System.__Canon is an internal mscorlib type used to make the canonical instantiation of a generic type.
b_ is a compiler generated backing field.
Simple example:
Public string MyString { get; set; }
so becomes something like:
private string b_MyString;
public string get_MyString() { return b_MyString; }
public void set_MyString(string value) { b_MyString = value; } / comments
System.__Canon is an internal mscorlib type used to make the canonical instantiation of a generic type.
b_ is a compiler generated backing field.
Simple example:
Public string MyString { get; set; ...
Hello,
If the performance difference was/is a uniform increase across the call-stacks then all you would see is the increase across all methods on the call-tree/methods-grid.
I would say look at 'All Methods' in the display options (just below the timeline) this will then display the framework stacks and this is where you would likely see differences for what you describe.
There is also quite a bit of functionality available in the profiler that is exposed via a context menu. If you mouse-right-click on a call-tree node you get numerous options, one of which is to 'expand the most expensive stack trace', this would be useful for faster drilling down.
If you find a likely candidate you could then search for its name use the 'Find Method' control (ctrl+f, Tools > Find...) when looking in another set of results.
Regarding Sampling mode; this mode will always give you timings that are as close to "normal running conditions" as you can get when under profile - since it does not instrument the IL of your application. / comments
Hello,
If the performance difference was/is a uniform increase across the call-stacks then all you would see is the increase across all methods on the call-tree/methods-grid.
I would say look at 'A...
Hello,
There are two likely reasons for the difference in timings that you are seeing when explicitly comparing a 32bit build under profile to a 64bit build under profile.
Firstly is the performance of the profiler itself due to memory addressing of pointers, pointers for 64bit are twice as large (more memory used, larger cache consumption); this can cause some deviation when compared to 32bit if you are comparing absolute timing values.
Another reason is when using a profiling mode of type 'Line Level timings...'; using these profiling modes mean the profiler has to make far more methods calls - with the 32bit profiler we can explicitly use the __fastcall calling convention as these methods are small. In comparison the 64bit profiler only has access to the one calling convention, that is similar to __fastcall but not quite (writes more to registers, writes to the stack). So in real terms this can add a significant difference to timings as we have to make large amounts of these method calls when recording line level data.
The short of it would be if comparing 32/64bit builds where you think there is a performance problem in one then look to percentages as they will be a better indication. Even better would be to do a quicker validation check by looking at a comparison using Sampling mode first, then if you think it is needed to delve deeper with the more intrusive/detailed profiling modes.
Also when comparing sessions remember there will be environmental conditions to consider, i.e. the load of the the machine due to other processes.
Hope that helps. / comments
Hello,
There are two likely reasons for the difference in timings that you are seeing when explicitly comparing a 32bit build under profile to a 64bit build under profile.
Firstly is the performanc...
Hello,
The way you would have to currently approach this would be to have a build step where you run a process for the command line profiler (available in APP Pro) that profiles the nunit command line runner and provide the arguments to the nunit runner for the assembly to process.
Provide the Profilers with command line arguments to profile child processes and output the results to an xml file.
Then assert on the content of the xml file for the particular methods running values.
Edit: also see this support item - http://www.red-gate.com/SupportCenter/c ... 0708000125 / comments
Hello,
The way you would have to currently approach this would be to have a build step where you run a process for the command line profiler (available in APP Pro) that profiles the nunit command l...
Hello,
As of version 7.2 this has been a known issue due to changes we made to how we record certain types of events.
Major known issues for releases can viewed here: http://www.red-gate.com/SupportCenter/C ... ceProfiler
I am afraid you will be unable to open those results in a 6.x version of the profiler.
Edit: Internal reference to this issue is PP-2446 / comments
Hello,
As of version 7.2 this has been a known issue due to changes we made to how we record certain types of events.
Major known issues for releases can viewed here: http://www.red-gate.com/Suppor...
Hello,
We have logged this under internal ticket PP-2404.
The problem being that when we originally did the work for IIS Express it was at version 7.5 which you know was 32bit only.
I will update this thread with any time-scales when they are available. / comments
Hello,
We have logged this under internal ticket PP-2404.
The problem being that when we originally did the work for IIS Express it was at version 7.5 which you know was 32bit only.
I will update t...
Hello Nick,
I take it this is v8 of IIS Express yes? / comments
Hello Nick,
I take it this is v8 of IIS Express yes?
You are welcome, and thank you for pointing that out. / comments
You are welcome, and thank you for pointing that out.
Hello,
Attach to .Net4 Process using Sampling mode for profiling is a limitation I am afraid, it is no by design.
You may of already attempted the following advice since you are now using the Attach to Process option - which is generally considered a more advanced use-case.
You will need to have desktop (rdp) access to the terminal server session where your application is going to be run.
Using the profiler start/profile the application so that it is running and then any interaction with the application from the mobile is then profiled. It may be necessary to run the profiler as Admin.
Generally speaking an application running on terminal server is not aware of how it is hosted, so the same type of workflow detailed above could be run on a regular development desktop. Unless of course there is something specific about the hosting environment you are wanting to take into account. / comments
Hello,
Attach to .Net4 Process using Sampling mode for profiling is a limitation I am afraid, it is no by design.
You may of already attempted the following advice since you are now using the Attac...
Hello,
Would there be any chance that you would be able to send us a results file for a session that exhibits this behaviour? A simple test application would suffice - if you are unable to send results for one of your products.
If so, you can send it to my email (buttons below).
Thanks,
Dene. / comments
Hello,
Would there be any chance that you would be able to send us a results file for a session that exhibits this behaviour? A simple test application would suffice - if you are unable to send res...