﻿<?xml version="1.0" encoding="utf-8"?><rss version="2.0"><channel><title>Ayende @ Rahien</title><link>http://ayende.com</link><description>Ayende @ Rahien</description><copyright>Copyright (C) Ayende Rahien  2004 - 2021 (c) 2026</copyright><ttl>60</ttl><item><title>Sasha Goldshtein commented on Creating objects - round 2</title><description>Oren, you are probably right that these numbers would not matter in a typical business environment.
  
  
However, part of my job is developing a soft-realtime .NET application framework with a spec of 300,000 messages passed per second.  When you're talking about numbers such as these, the difference between "new"-ing up an object and using Activator.CreateInstance is not something I would neglect (and in fact, there is a specific point in our framework where we use up-front code-generation to prevent using Activator.CreateInstance for types we do not recognize during compile-time).
  
  
Another thing to remember is that these numbers add up across your application.  There's one place where you used Activator.CreateInstance because you were lazy to optimize or generate code up-front.  Another place where you have unintentional boxing/unboxing.  Another object with a finalizer going to Gen2 and carrying lots of memory to Gen2 with it.  Another structure with some unaligned fields which produces cache collisions.  And the result is a big surprise when you run the code under a profiler and don't understand how come the cost is distributed EVERYWHERE in the codebase.
  
  
I totally agree that this might not be relevant for everyone.  But it is for me, and it's important for me to convey the message that there are applications where you must care about details as minute as these.
</description><link>http://ayende.com/3170/creating-objects-round-2#comment1</link><guid>http://ayende.com/3170/creating-objects-round-2#comment1</guid><pubDate>Fri, 29 Feb 2008 15:38:10 GMT</pubDate></item></channel></rss>