Background: I'm developing for the xbox and am at the optomising stage. I need to cut down on object allocations. One place to start is finding out where (un)boxing occurs.
I'm very new to IL (in that i've never looked at any!) and would like to avoid running DLLs through a dissassembler, hunting for the (un)box command then trying to work out what line of code it relates to.
Question: Are there any tools which will report this kind of thing (where (un)boxing occurs) for me?
EDIT: Made request below into its own question since it's fairly distinct from this one.
Many, many, bonus points for a way of tieing a GC heap dump back to lines of code where the object creations occured!!
This MSDN Magazine article details how to create an FxCop (Code Analysis) rule that detects boxing and unboxing and can present violations as a warning. The article is a little on the old side, but you should be able to adapt it to your needs.
There is a tool called BoxCop which does exactly that.
It is not really useful when trying to integrate the checks for boxing/unboxing into the build process. For that you would need some rule for FxCop.
Related
You load a foreign code example with libraries attached to it in Visual Studio. Now there is a method that you want to reuse in your code. Is there a function in VS that lets you strip the code from all unnecessary code to only have code left that is necessary for your current method to run?
It is not about the library. Loading a .sln or .csproj and having classes over classes when you just want one method out of it is a waste of performance, ram and space. It is about code you can easily omit or references(what I call libraries) you can easily omit. A part-question of this is: Which "using" statement do you need that is only necessary for your current method and the methods that pass paramaters to it? In short, showing relevant code only. Code that is tied to each other.
Let's use an example: You go to github and download source code in c#. Let's call the solution S. You open S in Visual Studio. You don't disassemble, you just load the source code of S, that is there in plain text. Then you find a method M - in plain text - that you want to use. M contains some objects whose classes were defined somewhere in the project. The goal is to recreate the surrounding only for this method to copy & paste it into my own solution without having red underlined words in almost every line within the method
after reading the question and the comments, I think I have a vague idea what you are referring to.
In case we ignore the context of the method you are referring, you can extract any code piece from a "library" by using a .NET decompiler and assembly browser.
There are many of them for free, such as:
dotPeek,
ILSpy
...
This will allow you to see the method's code. From there on, you can proceed as you like. In case your copy the method to your code base, you might still have to change it a bit in order to adapt it to work with your objects and context. If you don't, this will give you insight on how the method works and might help you to understand the logic, so you can write your own.
Disclaimer: With this post, I am pointing out that it is possible to extract code from an assembly. I am not discussing the ethics or legal perspective behind such actions.
Hope this helps,
Happy Coding!
If it`s just one method, look at the source code and copy it to your libarary. Make sure you make a comment where you obtained the code and who has the copyright! Don't forget to include the licence, which you should have done with a libary reference anyway.
That said it is currently not (official) possible to automaticly remove unused public declared code from a library (assembly). This process is called Treeshaking by the way. Exception: .NET Native.
But .NET Native is only available for Windows Store Apps. You can read more about it here.
That said, we have the JIT (Just in Time)-Compiler which is realy smart. I wouldn't worry about a few KB library code. Spend your time optimizing your SQL Queries and other bottlenecks. The classes are only loaded, when you actualy use them.
Using some unstable solutions or maintaining a fork of a library, where you use more then one method (with no documentation and no expertise, since it is your own fork) isn't worth the headache, you will have!
If you realy want to go the route of removing everything you do not want, you can open the solution, declare everything as internal (search and replace is your friend) and restore the parts to public, which are giving you are Buildtime error / Runtime error (Reflection). Then remove everything which is internal. There are several DesignTime tools like Resharper, which can remove Dead Code.
But as I said, it's not worth it!
For .NET Core users, in 6-8 weeks, we have the .NET IL Linker as spender has commented, it looks promising. What does this mean? The .NET framework evolves from time to time. Let it envolve and look at your productivity in the meantime.
I'm interested in finding all the places in my solution where boxing or unboxing occur. I know that I can use ildasm like this:
Ildasm.exe yourcomponent.dll /text | findstr box
but I prefer not to look at the MSIL level.
Is there an easy way to do this?
Clr Heap Allocation Analyzer is a free Visual Studio add-on that detects many (but not all) forms of boxing and will highlight your source code and provide a tooltip explanation.
You can also use the Visual Studio Diagnostic Tools to analyze memory allocations. This won't reveal boxing directly, but any time you see a value type on the heap you know it's been boxed (for example, you will see that a references to Int32 takes 12 bytes).
you can do it with FXCOP: (old article with example)
Link - Three Vital FXCop Rules
This is a perfect use case of #Roslyn The Compiler as a Service that is coming out from Microsoft and Jon Skeet as usual is absolutely right. I am writing a book on Roslyn to show how to do these sort of code analytics using Roslyn and top it off with some eye catching visualization by JavaScript.
Here is the code for finding boxing calls. However scope resolution plays a role. But this example should get you started. Pre-order your copy to get more such at https://www.amazon.com/Source-Analytics-Roslyn-JavaScript-Visualization/dp/1484219244?ie=UTF8&Version=1&entries=0
https://gist.github.com/sudipto80/43efdecb878cac17b340cda2c281c3b3
I recently found two posts in StackOverflow about adding comments in programming. Posts : 1,2
After going through these posts i was eager to know a thing a comments.i.e :
1.Do adding comments in programming utilize system resource while compiling the code ?
Yes they do, but you probably have to add a lot of them to notice any difference.
Handling white space and comments is part of the "lexing" (lexical analysis) phase of compilation, so yes, they do consume resources in the process. As a previous commenter has said, it's so computationally cheap that you'd have to insert a lot of comments and white space (and maybe compile on a really slow computer) before you'd notice.
You may be interested in this document: Notes on How Parsers and Compilers Work.
The first rule of programming: write code that other people can easily read and modify. To achieve this:
Write short, clear, code blocks that are easy to read and thus easy to determine the "what".
Write unit tests to both convey the "why" and to provide a safety net when maintaining the code.
Everything else, including how long the code takes to compile, should be moot. So the answer to your question is "it doesn't matter".
This might be a duplicate, but I haven't seen this exact question or a similar one asked/answered with a date newer than the release of .Net 4.
I'm looking for a temporary hack that allows me to look through the call stack and get all calling objects (not methods, but the instances that hold the methods) in the stack. Ultimately I need their hashcodes.
Is this possible?
EDIT:
Whether it came across in my question or not, was really asking if there was a simple/built-in way to do this. Really, just a stop-gap fix until I can make breaking changes to other parts of the system. Thanks for the great answers. After seeing them, I think I'll wait . . . :)
What are you trying to achieve here?
Have a look at a similar question I answered about a month ago: How to get current value of EIP in managed code?. You might get some inspiration from that. Or you might decide it is too ugly (+1 for the latter).
If all you want to do is assemble 'unique' call paths within a program session, go right ahead: I'd be very sure to use an AOP weaver and thread local storage. It wouldn't be too hard that way.
Caveat 1: Hashes are not very useful for generic .NET objects
A random object's hashcode may vary with it's location on the heap to begin with. For reference: on MONO, with the moving heap allocator disabled, Object::GetHash is this pretty blob of code (mono/metadata/monitor.c)
#else
/*
* Wang's address-based hash function:
* http://www.concentric.net/~Ttwang/tech/addrhash.htm
*/
return (GPOINTER_TO_UINT (obj) >> MONO_OBJECT_ALIGNMENT_SHIFT) * 2654435761u;
#endif
Of course, with the moving allocator things are slightly more complex to guarantee a constant hash over the lifetime of the object, but you get the point: each runtime will generate different hashes, and the amount of allocations done will alter the future default hash codes of the identical objects.
Caveat 2: Your stack will contain alien frames
Even if you got that part fixed by supplying proper deterministic hash functions, you will require each stackframe to be of 'recgonizable' type. This is probably not going to be the case. Certainly not if you use anything akin to LINQ, anonymous types, static constructors, delegates; all kinds of things could be interleaving stack frames with those of (anonymous) helper types, or even performance trampolines invented by the JIT compiler to optimize tail recursion, a large switch jump table or sharing code between multiple overloads.
Takeaway: stack analysis is hard: you should definitely use the proper API if you are going to undertake it.
Conclusion:
By all means have a ball. But heed the advice
your requirements are non-standard (underlined by the runtime library not supporting it); This is usually a sign that: you are solving a unique problem (but reconsider the tool chosen?) or you are solving it the wrong way
You could perhaps get a lot more info by generating a flow graph with some handwritten simulation code instead of trying to hook into the CLR VM
if you're gonna do it, use the proper API (probably the profiler API since a sampling profiler will save exactly this: stack 'fingerprints' every so-many instructions)
If you really must do it by instrumenting your code, consider using AOP
You can get the call stack by creating an instance of the StackTrace class and inspecting the StackFrame objects within it. Looking at the member list, this doesn't seem to reveal the instances, though, just the classes and methods.
This is possible only with unmanaged APIs, specifically with the CLR profiling API. I know nithing about it, other than it is used to implement profiling and debugging tools. You have to google it and be comfortable with burning 1 week bringing it to production. If at all possible, give up your plan and find an alternative. Tell us what you want to do and we can help!
Try Environment.StackTrace.
Creating a call stack diagram
We have just recently been thrown into a big project that requires us to get into the code (duh).
We are using different methods to get acquainted with it, breakpoints etc. However we found that one method is to make a call tree of the application, what is the easiest /fastest way to do this?
By code? Plugins? Manually?
The project is a C# Windows application.
With the static analyzer NDepend, you can obtain a static method call graph, like the one below. Disclaimer: I am one of the developers of the tool
For that you just need to export to the graph the result of a CQLinq code query:
Such a code query, can be generated actually for any method, thanks to the right-click menu illustrated below.
Whenever I start a new job (which is frequently as I am a contractor) I spend two to three days reading through every single source file in the repository, and keep notes against each class in a simple text file. It is quite laborious but it means that you get a really good idea how the project fits together and you have a trusty map when you need to find the class that does somethnig.
Altought I love UML/diagramming when starting a project I, personally, do not find them at all useful when examining existing code.
Not a direct answer to your question, but NDepend is a good tool to get a 100ft view of a codebase, and it enables you to drill down into the relationships between classes (and many other features)
Edit: I believe the Microsoft's CLR Profiler is capable of displaying a call tree for a running application. If that is not sufficient I have left the link I posted below in case you would like to start on a custom solution.
Here is a CodeProject article that might point you in the right direction:
The download offered here is a Visual
Studio 2008 C# project for a simple
utility to list user function call
trees in C# code.
This call tree lister seems to work OK
for my style of coding, but will
likely be unreliable for some other
styles of coding. It is offered here
with two thoughts: first, some
programmers may find it useful as is;
second, I would be appreciative if
someone who is up-to-speed on C#
parsing would upgrade it by
incorporating an accurate C# parser
and turn out an improved utility that
is reliable regardless of coding style
The source code is available for download - perhaps you can use this as a starting point for a custom solution.
You mean something like this: http://erik.doernenburg.com/2008/09/call-graph-visualisation-with-aspectj-and-dot/
Not to be a stuck record, but if I get it running and pause it a few times, and each time capture the call stack, that gives me a real good picture of the call structure that accounts for the most time. It doesn't give me the call structure for things that happen real fast, however.