Sasha Goldshtein, Dima Zurbalev, Ido Flatow
Maximizing the performance of your algorithms and applications is extremely important and can give you a competitive advantage, a lower cost of ownership, and happier users. Pro .NET Performance explains the internals of Windows, the CLR, and the physical hardware that affect the performance of your applications, and gives you the knowledge and tools to measure how your code performs in isolation from external factors. The book is full of C# code samples and tips to help you squeeze every bit of juice from your application—lower memory utilization, consistent CPU usage, and fewer I/O operations across the network and disk. Pro .NET Performance will change the way you think about .NET application development. Guides you through performance measurement with a variety of profilers and other tools Explains how OS and CLR internals affect your application’s performance in unexpected ways Provides you with tips and real-life case studies for improving application performance What you’ll learn Measure your code’s performance with profilers and other tools. Understand where the bottlenecks are and focus on the right area for performance improvement. Manage memory efficiently by interacting properly with the garbage collector. Avoid common pitfalls by choosing the right abstractions. Understand the performance implications of the underlying operating system and runtime. Improve the performance of your applications by parallelization, caching, micro-optimization, and other techniques. Who this book is for Pro .NET Performance is for working .NET developers who care about the performance of their applications. It requires basic familiarity with Windows and the CLR, but guides the reader along the way and does not require prior experience with any performance-measurement tools. Pro .NET Performance also offers practical tips, case studies, and low-level knowledge for experienced developers and architects. Table of ContentsChapter 1: Performance Metrics Chapter 2: Performance Measurement Tools Chapter 3: Type Internals Chapter 4: Garbage Collection and Finalization Chapter 5: Collections and Generics Chapter 6: Concurrency and Parallelism Chapter 7: Networking, I/O, and Serialization Chapter 8: Unsafe Code and Interoperability Chapter 9: Algorithm Optimization Chapter 10: Performance Patterns Chapter 11: Web Application Performance
In my aspx pages, I call a COM component that uses STA. So I use aspcompat=true parameter, but I want to understand the logic. What does it exactly do? As far as I know, in STA, it is assumed to be called only by one thread. So I should provide the thread safety myself.
If that's right, where does aspcompat parameter provide the thread safety? On the whole page, or just the point where I access the STA component?
This is a quote taken from; Pro .NET Performance
AsP.nET executes pages on MTA threads by default. If you call sTA objects, they undergo marshaling. If you predominantly call sTA objects, this will degrade performance. you can remedy this by marking pages with the ASPCOMPAT attribute, as follows:
<%@Page Language = "vb" AspCompat = "true" %>
note that page constructors still executes in an MTA thread, so defer creating sTA objects to Page_Load and Page_Init events.
I was reading the Pro .Net Performance book section on reference type internals. It mentions that for a 32 bit .net process a reference type has 4 bytes of object header and 4 bytes of method table pointer. Also, says that on a 32 bit system, the objects are aligned to the nearest 4 byte multiple, which makes the minimum size of a reference type 12 bytes.
My question is, why is the minimum size 12 bytes? The object is 8 bytes and that already aligns with a 4 byte boundary.
Minimum of 12 bytes is a requirement of the garbage collection implementation.
The Base Instance Size is the size of the object as computed by the class loader, based on the field declarations in the code. As discussed previously, the current GC implementation needs an object instance of at least 12 bytes. If a class does not have any instance fields defined, it will carry an overhead of 4 bytes. The rest of the 8 bytes will be taken up by the Object Header (which may contain a syncblk number) and TypeHandle.
TypeHandle being a handle to the method table).