.Net: How much slower when calling PropertyInfo.SetValue?

Link: internals from CLR team about this.

This question has been around in my mind for a while so I decide to give it a test.
The test is simple, directly set property value, verse using PropertyInfo to set the value. To make things more interesting, I also tested set value in Dictionary.

The result: 232 times (27166 / 117) slower!
In 1 million test runs,

• direct access value: 117 milliseconds
• PropertyInfo: 27166 milliseconds
• Dictionary: 266 milliseconds

My conclusion: unless the logic is in the UI, or you really have to, don't use reflection for large performance critical jobs.

class Employee
{
private string _firstName;
private string _lastName;

public string FirstName
{
get { return _firstName; }
set { _firstName = value; }
}
public string LastName
{
get { return _lastName; }
set { _lastName = value; }
}

[TestMethod]
public void PropertyPerformanceTest()
{
int maxLoop = 1000000;
long durationDirect = 0;
long durationProperty = 0;
long durationDictionary = 0;

Stopwatch sw = new Stopwatch();
sw.Start();
for (int i = 0; i < e =" new" firstname = "Joan" lastname = "Smith" durationdirect =" sw.ElapsedMilliseconds;" pilastname =" typeof(Employee).GetProperty(" pifirstname =" typeof(Employee).GetProperty(" i =" 0;" e =" new" durationproperty =" sw.ElapsedMilliseconds;"> employeeValue = new Dictionary();
employeeValue.Add("LastName", null);
employeeValue.Add("FirstName", null);
sw.Start();
for (int i = 0; i < e =" new" durationdictionary =" sw.ElapsedMilliseconds;"> durationDictionary);
Assert.IsTrue(durationDictionary > durationDirect);
}

Software Engineer Productivity

Is this a myth?

Enough said.

Wouldn't it be easier to treat software engineers like building bricks and add / remove / replace them as needed? So whenever you want to grow, buy more, whenever facing financial pressure, remove some?

Unfortunately, that's not the way system works.
It's still take quite some effort / experience to learn which part of the your internal system is core asset and which parts is less dependent on domain knowledge and engineering insight. The latter part could be outsourced much more easily, but the core asset is not.

The other myth. As far as I saw, software engineering is still like an art, much or less. Yes, every one after some training can work as an carpenter. Does every carpenter produce the same quality of work in a similar time?

'Reuse' Is Not Usable

When it comes to code sharing, many times it is either not done at all, or only in a very minimal fashion, or heavily shared but super complicated -- meaning, shared once, but no one use that after they were shared.

Is there a balance? I have been always battling between sharing the code and keeping code simple. What's the principle or guidelines to follow?

When to share? When not? Or what are not sharable?
Below is the list I come up with:
1. Interface sharing. If the interface could be defined clear enough that any one (developer) comes and understand it right away, share it. If the shared interface became layer by layer, function plus function, specialized here and there for a particular implementation, don't share it.
2. Function sharing. Surprisingly, this is the best sharing technique. It provides two main benefits: a. Scalable. b. Focused logic (any function should be implemented within one page).
... to be filled

Rule of thump

1. Copy / paste code is never a good idea.
2. If it turns out you spend more time and make tremendous effort to reuse some simple stuff, you probably over shared the code
3. Refer to rules above and try writing reusable code as much as possible.

And I liked this link...