C# and performance with cast and hashtable

[mickey]

What's better, please?

void myFunction() {     
    calc ( _listNode[0].MyTable["Name"].ToString() );
    print( _listNode[0].MyTable["Name"].ToString() );
    SomeOtherOperation onThatIstance( _listNode[0].MyTable["Name"].ToString() );
}

void myFunction() {     
    calc ( _listNode[0].MyTable["Name"].ToString() );
    print( _listNode[0].MyTable["Name"].ToString() );
    SomeOtherOperation onThatIstance( _listNode[0].MyTable["Name"].ToString() );
}

To copy to clipboard, switch view to plain text mode 

void myFunction() {     
     string s = _listNode[0].MyTable["Name"].ToString() ;
    calc (s);
    print(s);
    SomeOtherOperation onThatIstance(s);
}

void myFunction() {     
     string s = _listNode[0].MyTable["Name"].ToString() ;
    calc (s);
    print(s);
    SomeOtherOperation onThatIstance(s);
}

To copy to clipboard, switch view to plain text mode 

[ashukla]

void myFunction() {     
string s = _listNode[0].MyTable["Name"].ToString() ;
calc (s);
print(s);
SomeOtherOperation onThatIstance(s);
}

void myFunction() {     
string s = _listNode[0].MyTable["Name"].ToString() ;
calc (s);
print(s);
SomeOtherOperation onThatIstance(s);
}

To copy to clipboard, switch view to plain text mode 

In above code there is a syntactical mistake. Here should be a toString() in spite of ToString. The above code is more suitable because first we should hold the variable and then process upon it. Otherwise repeatiation of same calculation exists.

[wysota]

I don't know how C# handles that, but C++ compiler should be able to optimize the first block to look like the second one, so the performance should be equal.

[spud]

I don't know how C# handles that, but C++ compiler should be able to optimize the first block to look like the second one, so the performance should be equal.

Why so? How should the compiler know that MyTable["Name"] always returns the same value?

[wysota]

How should the compiler know that MyTable["Name"] always returns the same value?

I don't know... heuristics? analysis? For methods such as "toString()" it should be easily achievable by looking at what it actually does.

[spud]

I don't know. What if the function was called randomString(), or currentTime()? We'd be in serious trouble if the compiler started making such assumptions.

[wysota]

I don't know. What if the function was called randomString(), or currentTime()?

At some point you'd encounter a volatile or non-const statement. You can trace if an object is modified or what is assigned where and if the assignment has a chance to mutate an object or not. I don't know if such checks are made but I don't see a reason not to do them (provided they are not more expensive than the gain). Consider the following code:

class A {
public:
  A(int x, int y) : _x(x), _y(y){}
  String toString() const { return String(_x)+"x"+String(_y); }
private:
  int _x, _y;
}

class A {
public:
  A(int x, int y) : _x(x), _y(y){}
  String toString() const { return String(_x)+"x"+String(_y); }
private:
  int _x, _y;
}

To copy to clipboard, switch view to plain text mode 

By looking at the constructor you see that _x and _y are nonvolatile ints that are not changed by calling toString() (because the method is const) and by inspecting the String class you might notice its constructor performs the same steps given the same argument and that concatenation of String objects is stationary (in terms of time) as well. etc. Compilers are getting smarter each day. They can let you know about uninitialized values or reading/writing out of bounds, then why not this?

[spud]

At some point you'd encounter a volatile or non-const statement. You can trace if an object is modified or what is assigned where and if the assignment has a chance to mutate an object or not. I don't know if such checks are made but I don't see a reason not to do them (provided they are not more expensive than the gain). Consider the following code:

class A {
public:
  A(int x, int y) : _x(x), _y(y){}
  String toString() const { return String(_x)+"x"+String(_y); }
private:
  int _x, _y;
}

class A {
public:
  A(int x, int y) : _x(x), _y(y){}
  String toString() const { return String(_x)+"x"+String(_y); }
private:
  int _x, _y;
}

To copy to clipboard, switch view to plain text mode 

By looking at the constructor you see that _x and _y are nonvolatile ints that are not changed by calling toString() (because the method is const) and by inspecting the String class you might notice its constructor performs the same steps given the same argument and that concatenation of String objects is stationary (in terms of time) as well. etc. Compilers are getting smarter each day. They can let you know about uninitialized values or reading/writing out of bounds, then why not this?

Well if the functions are in different compilation units and the code isn't inlined, then the compiler doesn't have access to that information.

[wysota]

That's not entirely true. Some compilers (for example MSVC) can do optimizations across compilation units. And seriously there is nothing preventing the compiler from storing some meta-data if it's needed later.