CLR via C# (4th Edition) (Developer Reference)

Author: Jeffrey Richter
4.3
All Stack Overflow 22
This Month Hacker News 1

CLR via C# (4th Edition) (Developer Reference)

4.3

Review Date:

Comments

by bold_monkey   2018-01-25
It depends on your goals, if you want a deep understandigyou must learn ho CLR works:

This book can be a good start: > https://www.amazon.com/CLR-via-4th-Developer-Reference/dp/07...

Anyway, if you have specific needs, the knowledge needed may vary. For LOB applications (IMHO) very often performance issue have to be searched in I/O (RDMS / WebServices / RPC), these times in all depends a lot on query tuning, optimization of data transfer via specific binary protocols etc... so C# internals not come to an help (even if i think that knowing it may be really precious).

If you are facing applications with numerical analysis and/or greedy algorithm you could give a look at stackalloc/unsafe programming. This links is a good start:

http://content.atalasoft.com/h/i/58208059-improving-performa...

Hope this helps :)

by anonymous   2017-11-13
This one: https://www.amazon.com/CLR-via-4th-Developer-Reference/dp/0735667454?
by anonymous   2017-08-20

While the exact details of the type system are implementation dependent, let me go into some more detail than just stating that it depends and you should not care. I'll describe how it approximately works in Microsoft's implementation (.NET) according to the book CLR via C# by Jeffrey Richter and the article See How the CLR Creates Runtime Objects by Hanu Kommalapati et al. (original MSDN May 2005 issue).


Say you have a class:

class Foo
{
    // Instance fields
    string myBar = "Foobar";
    int myNum;

    // Static fields
    static string bar = "Foobar";
    static int num;
}

Foo myFoo = new Foo();
Type typeOfFoo = typeof(Foo);

Where do the instance fields live?

Whenever you say new Foo(), space is allocated and initialized for the object instance, and the constructor is called. This instance is shown as instance of Foo in the image below. Such as instance contains only the instance fields of the class (in this case myBar and myNum), and for objects allocated on the heap two extra fields used by the runtime (Sync block index and Type handle). The type handle is a pointer to a Type object that describes the type of the instance, in this case type of Foo.

When you say new Foo() again, new space is allocated which will again contain space for the instance fields of the type. As you can see, instance fields are associated with object instances.

The runtime puts each instance field at a fixed offset from the start of the object's data. For example, myBar might live at offset +4. The address of the instance field is simply the address of the object plus the offset of the field.

Where do the static fields live?

Static fields in C# and Java are not associated with any object instance, but with a type. Classes, structs and enums are examples of types. Only once (per type) is some space allocated to hold the values of the static fields. It would make sense to allocate space for the static fields in the Type structure that describes the type, since there is also only one Type object per type. This is the approach taken by C# and Java.

The Type object1 is created when the type is loaded by the runtime. This structure contains all sorts of information needed for the runtime to be able to allocate new instances, call methods and perform casting, among other things. It also contains the space for the static fields, in this case bar and num.

The runtime has put each static field at some offset from the start of the type's data. This is different for each type. For example, bar might live at offset +64. The address of the static field is the address of the Type object plus the offset of the field. The type is statically known.

Displays some object structures, and their relationships.

1) In Microsoft .NET multiple different structures describe a type, such as the MethodTable and the EEClass structures.

by anonymous   2017-08-20

I'd say, probably not. Although this question is a bit rhetorical, take a look at this article/book excerpt, by Jeffrey Richter, Stop the madness (from the book CLR via C#). It discusses just those things you ask.

If all we cared about was raw performance, then the optimum number of threads to have on any machine is identical to the number of CPUs on that machine. [...] All threads still have a kernel object, kernel-mode stack, and other resources allocated to them. This trend of creating threads willy-nilly because they are cheap has to stop; threads are not cheap—rather, they are expensive, so use them wisely.

I highly recommend that book. Well worth reading front to back, although it is fairly big, ~900 pages.

Multi-threading though is a very complex subject and cannot be easily answered in just a few lines, it is highly dependent on what you are trying to achieve. As always, it depends and you have to measure/evaluate/optimize any solution to get optimal performance. However, just routinely dishing out threads is probably not a good idea in general. As a side note, a managed thread allocates 1 MB stack memory, meaning that creating (and holding on to) threads in a .NET application can be very wasteful.

Also, just because a tread exists does not mean that it is consuming a full core. It may do some work, but it may also sit idle and wait for some work to come along (which is the most likely case, otherwise your overall CPU consumption would constantly be closer to 100 than 0). They do however consume, or more correct, waste system resources.

Introducing threads adds a significant amount of extra complexity to your application, even though many techniques are being introduced to make them easier to use (various parallel frameworks etc.). The underlying complexity is still there though, sometimes posing as harmless, but always ready to burst out into its true nature (timing issues, deadlocks, debugging complexity etc).

In short you might say, "Do not use multiple thread unless you have a reason to".
Even then, t(h)read lightly.

by anonymous   2017-08-20

Ahh, I finally figured it out. I found the following comment buried in ch. 27 of Jeffrey Richter's CLR via C#:

When a Timer object is garbage collected, its finalization code tells the thread pool to cancel the timer so that it no longer goes off. So when using a Timer object, make sure that a variable is keeping the Timer object alive or else your callback method will stop getting called.

My timer was getting gobbled up by the GC! I created a private variable in my AppointmentsControl class and that solved the problem.


What puzzles me is that the official documentation specifically prescribes the approach that I originally used. It's too bad that page doesn't allow user feedback.