Browse by Tags

All Tags » CLR Internals » Whidbey » Performance (RSS)

Performance inspiration found in List.Contains() method plus some additional functionality we can add.

While I was rewriting a more complete stack implementation I was using the actual generic stack as a guideline to make sure I implemented all of their methods and I came across their Contains implementation. There were some out of place operations in...

Performance: Refactoring generic List.RemoveAll... Speed lost in implementation and Array.Clear...

Well, I got railed after my previous posting on the List.RemoveAll method How is that RemoveAll method on the generic List actually implemented? . Apparently I'm not allowed to make basic comments anymore, and I quote "Now your remark is just information...

How does List<T>(IEnumerable<T>) avoid the costs of expanding the internal collection?

The interface IEnumerable<T> is just like the old interface IEnumerable. It allows a single method GetEnumerator which returns an IEnumerator<T>. This second interface has the property Current and a method for moving the index MoveNext . As...

How is that RemoveAll method on the generic List actually implemented?

We get lots of removal methods for the List<T> in Whidbey. You can Remove(T), or the first instance of some object or value. You an RemoveAt(int) and take something out of a given offset. You can even RemoveRange(int, int) and take out a whole group...

Performance: Whidbey generic Queue didn't get hit with the same performance stick as the generic Stack

I think I've narrowed down the new Whidbey generic Stack class to using a linked array Performance: Linked Arrays's now and later . I figured, hey, they must have used the same features in the Queue right? Not quite, in fact the generic queue can actually...

Performance: Linked Arrays's now and later

I love testing my code against the latest and greatest available in Whidbey. Turns out there are some collections that are insane when it comes to performance. One such collection is the generic Stack and of course the new Queue. Now both of these new...

Performance: Focusing on BinarySearch

If you take a look through Rotor you'll find a number of methods that have the signature TrySZ[...]. What these methods are meant to do is take intrinsic data types (int, float, long, etc...) and perform faster than normal operations on them. That is...

Performance: CustomAttributeData is NOT for performance in current releases

I've detailed a number of specific types of tests in order to measure various areas of working with custom attributes. I've been comparing the CustomAttributeData.GetCustomAttributes and Attribute.GetCustomAttributes methods since they have a similar...

Since I'm on collections, strongly typed arrays, versus List<T> for very large collections... I want a Decompose method...

Collections, are collection, are collections. NOT! Collections are arrays somewhere, at least in most cases. More often than not I find myself using an ArrayList (in V1/1.1) and then converting the said list to a strongly typed array for quickly running...

I'm going to do something unfair to make a point: int.TryParse versus DWC.NumberUtilities.

Note this is a completely unfair test because Whidbey is in Beta and all, but I'll throw it out there anyway. I went ahead and tested the original TryParseInt method (the completely unoptimized version that has been deprecated in the utility), against...
More Posts Next page »