Evil code

Micro-optimization: the surprising inefficiency of readonly fields

By jonskeet

Introduction Recently I’ve been optimizing the heck out of Noda Time. Most of the time this has been a case of the normal measurement, find bottlenecks, carefully analyse them, lather, rinse, repeat. Yesterday I had a hunch about a particular cost, and decided to experiment… leading to a surprising optimization. Noda Time’s core types are mostly value types – date/time values are naturally value types, just as DateTime and DateTimeOffset are in the BCL. Noda Time’s types are a bit bigger than most value types, however – the largest being ZonedDateTime, weighing in at 40 bytes in an x64 CLR … Continue reading Micro-optimization: the surprising inefficiency of readonly fields

Extension methods, explicitly implemented interfaces and collection initializers

By jonskeet

This post is the answer to yesterday’s brainteaser. As a reminder, I was asking what purpose this code might have: public static class Extensions  {      public static void Add<T>(this ICollection<T> source, T item)      {          source.Add(item);      }  } There are plenty of answers, varying from completely incorrect (sorry!) to pretty much spot on. As many people noticed, ICollection<T> already has an Add method taking an item of type T. So what difference could this make? Well, consider LinkedList<T>, which implements ICollection<T>, used as below: // Invalid LinkedList<int> list = new LinkedList<int>(); list.Add(10); That’s not valid code (normally)…. whereas this is: // … Continue reading Extension methods, explicitly implemented interfaces and collection initializers

Quick brainteaser

By jonskeet

Just a really quick one today… What’s the point of this code? Does it have any point at all? public static class Extensions {     public static void Add<T>(this ICollection<T> source, T item)     {         source.Add(item);     } } Bonus marks if you can work out what made me think about it. I suggest you ROT-13 answers to avoid spoilers for other readers.

More fun with DateTime

By jonskeet

(Note that this is deliberately not posted in the Noda Time blog. I reckon it’s of wider interest from a design perspective, and I won’t be posting any of the equivalent Noda Time code. I’ll just say now that we don’t have this sort of craziness in Noda Time, and leave it at that…) A few weeks ago, I was answering a Stack Overflow question when I noticed an operation around dates and times which should have been losing information apparently not doing so. I investigated further, and discovered some "interesting" aspects of both DateTime and TimeZoneInfo. In an effort … Continue reading More fun with DateTime

Type initializer circular dependencies

By jonskeet

To some readers, the title of this post may induce nightmarish recollections of late-night debugging sessions. To others it may be simply the epitome of jargon. Just to break the jargon down a bit: Type initializer: the code executed to initialize the static variables of a class, and the static constructor Circular dependency: two bits of code which depend on each other – in this case, two classes whose type initializers each require that the other class is initialized A quick example of the kind of problem I’m talking about would be helpful here. What would you expect this code … Continue reading Type initializer circular dependencies

Eduasync part 15: implementing COMEFROM with a horrible hack

By jonskeet

Ages ago when I wrote my previous Eduasync post, I said we’d look at a pipeline model of coroutines. I’ve decided to skip that, as I do want to cover the topic of this post, and I’ve got some more "normal" async ideas to write about too. If you want to look at the pipeline coroutines code, it’s project 20 in the source repository. Have fun, and don’t blame me if you get confused reading it – so do I. The code I am going to write about is horrible too. It’s almost as tricky to understand, and it does … Continue reading Eduasync part 15: implementing COMEFROM with a horrible hack

Upcoming speaking engagements

By jonskeet

It’s just occurred to me that I’ve forgotten to mention a few of the things I’ll be up to in the near-ish future. (I’ve talked about next week’s Progressive .NET session before.) This is just a quick rundown – follow the links for more blurb and details. .NET Developer Network – Bristol, September 21st (evening) I’ll be talking about async in Bristol – possibly at a high level, possibly in detail, depending on the audience experience. This is my first time talking with this particular user group, although I’m sure there’ll be some familiar faces. Come along if you’re in … Continue reading Upcoming speaking engagements

Of memory and strings

By jonskeet

This post was provoked by a recent Stack Overflow question which asked whether there was an efficient representation of ASCII strings in .NET. In particular, the questioner wanted to story hundreds of thousands – possibly millions – of strings in memory, and knowing (or assuming) that they all consisted of ASCII characters, he wanted to avoid the waste of space that comes from storing each character in a .NET string as a UTF-16 code unit. My answer to the question mostly consisted of saying that I didn’t think it would be worth the effort, and giving some reasons. But the … Continue reading Of memory and strings

Evil code – overload resolution workaround

By jonskeet

Another quick break from asynchrony, because I can’t resist blogging about this thoroughly evil idea which came to me on the train. Your task: to write three static methods such that this C# 4 code: static void Main() {     Foo<int>();     Foo<string>();     Foo<int?>(); } resolves one call to each of them – and will act appropriately for any non-nullable value type, reference type, and nullable value type respectively. You’re not allowed to change anything in the Main method above, and they have to just be methods – no tricks using delegate-type fields, for example. (I don’t know whether such … Continue reading Evil code – overload resolution workaround

There’s a hole in my abstraction, dear Liza, dear Liza

By jonskeet

I had an interesting day at work today. I thought my code had broken… but it turns out it was just a strange corner case which made it work very slowly. Usually when something interesting happens in my code it’s quite hard to blog about it, because of all the confidentiality issues involved. In this case, it’s extremely easy to reproduce the oddity in an entirely vanilla manner. All we need is the Java collections API. I have a set – a HashSet, in fact. I want to remove some items from it… and many of the items may well … Continue reading There’s a hole in my abstraction, dear Liza, dear Liza