Already a member? Log in

Sign up with your...

or

Sign Up with your email address

Add Tags

Duplicate Tags

Rename Tags

Share This URL With Others!

Save Link

Sign in

Sign Up with your email address

Sign up

By clicking the button, you agree to the Terms & Conditions.

Forgot Password?

Please enter your username below and press the send button.
A password reset link will be sent to you.

If you are unable to access the email address originally associated with your Delicious account, we recommend creating a new account.

Links 1 through 10 of 25 by Atif Aziz tagged clr

“When you are emitting a dynamic method and doesn't have a way to persist it, you can imagine that it could be hard to debug. But SoS has some build-in support for LCG that works surprisingly well.”

Share It With Others!

“Research published a few years back indicated that dispatching through a vtable incurred astonishing overheads, as high as 50% of total execution time. Alternative dispatch techniques based on runtime tests, such as a linear sequence of if statements checking for the various concrete class types, or a sequence of nested if statements forming a binary search, were often more efficient on a variety of hardware.”

Share It With Others!

“For CLR 4 the fact that the x64 JIT would sometimes not honor the “tail.” prefix prevented functional languages like F# from being viable. So we worked to improve the x64 JIT so that it could honor the “tail.” prefix all of the time and help make F# a success. Except where explicitly called out, x86 and IA64 remain unchanged between CLR 2 and CLR 4…”

Share It With Others!

“For CLR 4 the fact that the x64 JIT would sometimes not honor the tail. prefix prevented functional languages like F# from being viable. So we worked to improve the x64 JIT so that it could honor the tail. prefix all of the time and help make F# a success.”

Share It With Others!

Jon Skeet described how the runtime in the .NET Framework 4.0 has changed to defer type initialization even further than ever before.

Share It With Others!

One of the important additions to IronPython 2.6 is something that enables several important new ways of integrating with the .NET framework. One of the use cases is for .NET attribute support, which has long been missing from IronPython. The new feature is __clrtype__.

Share It With Others!

This project is a custom CLR host that can provide significant performance improvements for applications that consume large amounts of memory. This is accomplished by locking all CLR-allocated pages into physical memory. If enough physical memory is available, running an application under this host can guarantee that paging will not occur even if other applications on the system are allocating and deallocating memory continuously.

Share It With Others!

As of .NET 3.5 SP1, another set of APIs joins the existing interfaces. In .NET 3.5 SP1, it is possible to receive a notification when a garbage collector is approaching and act accordingly if application needs dictate it. These APIs are available only if concurrent GC is disabled, i.e. when using workstation non-concurrent GC or server GC.

Share It With Others!

Allocating buffers just before a slow I/O operation and then pinning them can result in excessive memory consumption because of heap fragmentation. To avoid these problems, buffers should be allocated during application startup and treated as a pool for all I/O operations. The sooner the objects are allocated, the sooner they can get into Gen 2. After the objects are in Gen 2, the cost of pinning is greatly reduced due to the lesser frequency of compaction.

Share It With Others!

Aside from short-lived LOH allocations, the most common cause of memory related issues in ASP.NET apps is pinning managed memory during long async I/O operations. ASP.NET itself does not do this. Objects larger than 85,000 bytes are allocated in the Large Object Heap (LOH). The LOH is not compacted and collection only occurs after a full collection (so generation 2 must be collected in order to collect an object in the LOH). Short-lived and frequent LOH allocations will kill the performance of an application.

Share It With Others!