Is there any performance cost for declaring a new variable in the next case:
This is an example just to demonstrate the point.
public class Person
{
public string FirstName { get; set; }
public string LastName { get; set; }
public int Age { get; set; }
}
And I have the next method:
Option 1:
public void MyMethod(Person person)
{
if (person.FirstName.Contains("Ro") || (person.LastName.StartsWith("A") && person.Age > 20))
{
//Do something
}
else if (person.FirstName.Contains("Ko") || (person.LastName.StartsWith("B") && person.Age >= 40))
{
//Do something
}
else if (person.FirstName.Contains("Mo") || (person.LastName.StartsWith("C") && person.Age > 60))
{
//Do something
}
else
{
//Do something
}
}
Option 2:
public void MyMethod(Person person)
{
string firstName = person.FirstName;
string lastName = person.LastName;
int age = person.Age;
if (firstName.Contains("Ro") || (lastName.StartsWith("A") && age > 20))
{
//Do something
}
else if (firstName.Contains("Ko") || (lastName.StartsWith("B") && age >= 40))
{
//Do something
}
else if (firstName.Contains("Mo") || (lastName.StartsWith("C") && age > 60))
{
//Do something
}
else
{
//Do something
}
}
Again, this is just an example to demonstrate the idea of the question.
The question: Is there any performance or memory issues between option 1 and option 2?
For sure, option 2 is looking better and is more readable.
This is tackled by the jitter, it aggressively eliminates local variables of a method and looks for ways to store them in a CPU register instead. It does this whether or not you declare the variable yourself. Your property getters are simple and have no side-effect, something the jitter can find out by itself. Those getter methods are eliminated as well, they are inlined. In effect, it will transform your code from the 1st snippet to the second snippet.
This is the core reason that you cannot find out what local variables a method has through Reflection. And why you have a problem debugging optimized code. And why the volatile keyword exists in C#. A local variable simply doesn't exist anymore when the jitter optimizer is done with it.
You'll find an overview of the kind of optimizations performed by the jitter in this answer.
So, no, don't hesitate to make your code more readable this way, it is not expected to have any perf impact. Do keep in mind however that you can introduce a bug in your code doing this, it will trigger when the rest of your code affects the object you are using. You'll of course store a stale value of the property. This is not always that obvious if the class is non-trivial and the property getter has side-effects itself. Otherwise the core reason that coding guidelines in .NET demand that properties with side effects should be methods instead.
Meh, I find option 1 more readable. Option 2 implies that you're manipulating the values of those properties. It takes a second or two of parsing the code to figure out that you're not.
So it's just a stylistic choice. Consult your style guide to see which is preferred by your organization or particular code base.
The performance difference will be exactly nil. You probably won't trust me on this, and if not, the only way to be sure is to actually benchmark it for yourself. But that's really a waste of time.
A property getter should (unless the documentation specifies otherwise) have constant-time execution, so querying the value of the property should be no different than querying the value of a local variable. So the only other thing that could possibly impact performance is that, with option 2, you could possibly end up querying the value of all the properties, when your code might never get to the branch that requires the last name or the age. But that's probably going to be highly variable. You can really only determine this by repeated benchmarking with some real-world data. And don't waste your time unless this method is really proven to be a bottleneck. And it won't be.
If you're going to make a decision on some basis other than readability, it would be thread-safety. If the value returned by a property getter can potentially change after another thread modifies the object, then you might have a problem using Option 1. That would make caching the value of those properties into local variables more desirable, thus you'd choose Option 2.
But that is precisely why the compiler is not going to do any type of caching, turning Option 1 into Option 2, as some of the other answers suggest. The generated code will be different, the performance difference just won't be significant. (Although the JITter may certainly perform this type of optimization at run-time, as Hans points out in his answer.)
Complexity of both is same. So i think both are equal in both regards.
In practice there will be no difference in performance, I doubt you would be able to measure any difference even if you ran the code a billion times.
With that said, there is a difference. A property get operation is in fact a method call, so the first operation will call the person.get_FirstName method when you access the property. This means that there may, depending on how the compiler optimizes your code, be some difference in how your code behaves.
So there will not be any measurable difference and you should go for the most readable option. :-)
Related
Imaginge this class
Class Person
{
public string Name { get; set; }
public int SomeExpensiveCalculation {
get {
return TimeConsumingCalulation(Name )
}
}
}
Since get is a method, I assume, when the the property "SomeExpensiveCalculation" is never requested or used, the function "TimeConsumingCalulation" is never executed. Is this correct?
That's correct. Property getter is just a method that executes when called.
But properties should be simple, avoid expensive calculations inside the property get.
That is correct. Properties are just Syntax Sugar for GetValue and SetValue function pairs. I think they also had some added reflection support.
With Time Consuming Operation for a value that may not be needed, maybe a Lazy[T] would be a good tool? It might at least be clearer that Lazy Initialsiation is your intention. Between it and WeakRefrence[T], you can usually cover edge cases with Memory allocation or time consumption.
However wich code is actually executed at runtime is a bit tricky. .NET has this Feature called a "just in time" compiler, and it may or may not do all kinds of Optimsiations. It can add a temporary variable to avoid retrieving the same collection value twice. Or cut unused temporary variables. Cut out a large part of the bounds checks in a array accessor.
Inling properties is way up there, but usually this will not affect any working of it.
I have a situation:
I nee to do something with a class.
What should be more efficiente, modify the method this way witf IFs or created methos for each action?
public value Value(int command)
{
if (command == 1)
{
DoSomething1();
}
if (command == 2)
{
DoSomething2();
}
else
{
return empty();
}
}
There are going to be like 50 o more of this commands.
Whats isbetter in terms of performance on execution and size of the exectuable?
At a high-level, it looks like you're trying to implement some kind of dynamic-dispatch system? Or are you just wanting to perform a specified operation without any polymorphism? It's hard to tell.
Anyway, based on the example you've given, switch block would be the most performant, as the JIT compiler converts it into an efficient hashtable lookup instead of a series of comparisons, so just do this:
enum Command { // observe how I use an enum instead "magic" integers
DoSomethingX = 1,
DoSomethingY = 2
}
public Value GetValue(Command command) {
switch(command) {
case Command.DoSomethingX: return DoSomethingX();
case Command.DoSomethingY: return DoSomethingY();
default: return GetEmpty();
}
}
I also note that the switch block also means you get more compact code.
This isn't a performance problem as much as it is a paradigm problem.
In C# a method should be an encapsulation of a task. What you have here is a metric boatload of tasks, each unrelated. That should not be in a single method. Imagine trying to maintain this method in the future. Imagine trying to debug this, wondering where you are in the method as each bit is called.
Your life will be much easier if you split this out, though the performance will probably make no difference.
Although separate methods will nearly certainly be better in terms of performance, it is highly unlikely that you should notice the difference. However, having separate methods should definitely improve readability a lot, which is a lot more important.
For discussion, I have this class with properties
public class Intresting
{
decimal _mQty, _mSpareQty;
public Qty { get { return _mQty; } set { _mQty = value; } }
public SpareQty { get { return _mSpareQty; } set { _mSpareQty= value; } }
public SparePercentage
{
get { return _mQty == 0 ? 0 : _mSpareQty / _mQty; }
set { _SpareQty = Qty * value; }
}
}
I am concern If I have 1,000,000 Interesting objects displayed in a custom GridView in a read only situation which shows SparePercentage via the property, the SparePercentage will be calculated over and over again or will there be optimised for example using a third _mSpareQtyPercentage which gets recalculated when Qty and SpareQty is set?
I very much doubt that there's anything in the JIT which would perform that optimization for you - after all, that requires more work each time Qty and SpareQty are set, and more space per object. That's not a trade-off the JIT should be doing for you. You could do that yourself, of course - just don't expect either the C# or JIT compiler to do it for you.
I would expect the JIT compiler to inline your trivial properties - which can be written as automatically implemented properties as of C# 3:
public decimal Quantity { get; set; }
public decimal SpareQuantity { get; set; }
(Note the changes to make the names more readable at the same time, by the way.)
The JIT will do nothing in particular to optimize this property and it will hence be re-evaluated in full every time it's asked for. However I doubt this would ever show up as a source of performance problems in your application. I certainly wouldn't go thruogh the troulbe of caching the result myself until a profile noted that as a problem in my application.
Note: It's also odd to have a property which has a get which is a calculation and has a set at all. When there is a calculation in the getter I usually prefer to avoid a setter entirely and instead force the caller to mutate the underlying values that are a par of the calculation
No, it will perform the calculation every time it is called. If you want to avoid that, you will have to implement your own cacheing.
.NET doesn't "optimize" properties any more than it optimizes any other functions.
This is one reason it is not recommended to put more than a getter to the backing field. If there is an operation to be performed, it should occur in a method. There is nothing in the compiler that would make an assumption about how the code should be executed.
The sample will execute the formula every time that getter is called. OT, but in a threaded environment, I would expect that the only way I could get the value would be to call a method.
I have read that a variable should never do more than one thing. Overloading a variable to do more than one thing is bad.
Because of that I end up writing code like this: (With the customerFound variable)
bool customerFound = false;
Customer foundCustomer = null;
if (currentCustomer.IsLoaded)
{
if (customerIDToFind = currentCustomer.ID)
{
foundCustomer = currentCustomer;
customerFound = true;
}
}
else
{
foreach (Customer customer in allCustomers)
{
if (customerIDToFind = customer.ID)
{
foundCustomer = customer;
customerFound = true;
}
}
}
if (customerFound)
{
// Do something
}
But deep down inside, I sometimes want to write my code like this: (Without the customerFound variable)
Customer foundCustomer = null;
if (currentCustomer.IsLoaded)
{
if (customerIDToFind = currentCustomer.ID)
{
foundCustomer = currentCustomer;
}
}
else
{
foreach (Customer customer in allCustomers)
{
if (customerIDToFind = customer.ID)
{
foundCustomer = customer;
}
}
}
if (foundCustomer != null)
{
// Do something
}
Does this secret desires make me an evil programmer?
(i.e. is the second case really bad coding practice?)
I think you've misunderstood the advice. In that case, you're only using the variable for one purpose - to store the customer being searched for. Your logic checks to see if the customer was found, but doesn't change the purpose of the variable.
The "don't use variables for more than one thing" is aimed at things like "temp" variables that store state for ten different things during the course of a function.
You're asking about and demonstrating 2 different things.
What you're asking about: Using the same variable for 2 different things. For example storing a user's age and also his height with a single double variable.
What you're demonstrating: Using 2 variables for the same purpose.
I like your second code variant better, you have 1 variable not 2 that are co-dependent. The first piece of code may have more problems as you have more state to manage to signify the same exact thing.
I think the root thing that you're asking about is: Is it ok to use a magic value instead of a separate variable? It depends on your situation, but if you are guaranteed that the magic value (null in this case) can't be used otherwise to signify anything else, then go ahead.
When you would use the first variant of code that you gave:
If you can have a null value even if an object is found, and you need to distinguish that between actually finding a customer or not, then you should use the 2 variable variant.
Personally, I'd consider refactoring this into methods to find and check your customer, thereby reducing this block length dramatically. Something like:
Customer foundCustomer = null;
if (!this.TryGetLoadedCustomer(out foundCustomer))
foundCustomer = this.FindCustomer();
if (foundCustomer != null)
{ // ...
That being said, you're using the foundCustomer variable for a single purpose here, in both cases. It's being used in multiple places, but it's used for a single purpose - to track the correct customer.
If you're going to use the code as you have it above, I personally prefer the second case over your first option - since a null check is probably going to be required in any case.
The second way is better in my opinion as well. I'd say the first way is actually wrong, as you have two variables that depend on each other and give you redundant information. This opens the possibility of them being inconsistent - you can make a mistake and have customerFound be true, but foundCustomer be null. What do you in that case? It's better for that state to be impossible to reach.
I would say the second case is better than the first. Checking a variable against NULL does not constitute an entire other usage in my book. The second case is better because you have copied code in the first where you have to set the flag and set the variable. This is error prone if you had another case where you set the Customer but then forgot to set the flag.
In the second piece of code, a null value of foundCustomer indicates that no customer was found. This sounds perfectly reasonable, and I would not consider that to be a double use of the variable at all.
I think the second option makes pretty good sense. Why waste a variable if you can live without it?
But in the foreach statement I would add a break if the customer is found.
HTH
I'd argue the opposite. You're actually adding additional lines of code to achieve the same result which makes your first code example more prone to errors and harder to maintain.
I agree with the consensus, you're doing fine checking for nulls, the advice is really warning against something horrid like:
float x;
x=37; // current age
if (x<50) {
x=x/10; // current height
if (x>3) {
x=3.14; // pi to the desired level of precision
}
}
if (x==3.14) {
// hooray pi for everyone old enough
}
else {
// no pi for you youngster!
}
btw, I know it's just a wee code snippet, but I can't help but think that there is something wrong with:
if (customerIDToFind = currentCustomer.ID)
{
foundCustomer = currentCustomer;
}
else {
// foundCustomer remains null
}
if (!foundCustomer) {
// always true when currentCustomer.IsLoaded
}
That would mean that once you have a loaded customer then you'll never again search for another one. I'm guessing that you pruned a bit of handy code to make an example, if that's the case then please ignore this part of the comment! ;-)
I think that if you make it your mission to create simple code that other developers can understand easily, if you make that your beacon instead of a set of rigid rules from 1985, you will find your way.
There are a lot of practices that come from old school procedural development, where routines were more likely to be monolithic and extremely long. We can still learn from them, don't get me wrong, but we have many new strategies for handling complexity and creating human readable/self describing code, so to me the idea that this should be a hard and fast rule seems obsolescent at best.
That said, I would probably refactor this code into a two or three smaller methods, and then the variable reuse question would probably go away. :)
I'd use the second version, but I'm not sure if your sample was very good because I don't think that it is doing two things. Checking a variable for null is standard practice.
I often find myself writing a property that is evaluated lazily. Something like:
if (backingField == null)
backingField = SomeOperation();
return backingField;
It is not much code, but it does get repeated a lot if you have a lot of properties.
I am thinking about defining a class called LazyProperty:
public class LazyProperty<T>
{
private readonly Func<T> getter;
public LazyProperty(Func<T> getter)
{
this.getter = getter;
}
private bool loaded = false;
private T propertyValue;
public T Value
{
get
{
if (!loaded)
{
propertyValue = getter();
loaded = true;
}
return propertyValue;
}
}
public static implicit operator T(LazyProperty<T> rhs)
{
return rhs.Value;
}
}
This would enable me to initialize a field like this:
first = new LazyProperty<HeavyObject>(() => new HeavyObject { MyProperty = Value });
And then the body of the property could be reduced to:
public HeavyObject First { get { return first; } }
This would be used by most of the company, since it would go into a common class library shared by most of our products.
I cannot decide whether this is a good idea or not. I think the solutions has some pros, like:
Less code
Prettier code
On the downside, it would be harder to look at the code and determine exactly what happens - especially if a developer is not familiar with the LazyProperty class.
What do you think ? Is this a good idea or should I abandon it ?
Also, is the implicit operator a good idea, or would you prefer to use the Value property explicitly if you should be using this class ?
Opinions and suggestions are welcomed :-)
Just to be overly pedantic:
Your proposed solution to avoid repeating code:
private LazyProperty<HeavyObject> first =
new LazyProperty<HeavyObject>(() => new HeavyObject { MyProperty = Value });
public HeavyObject First {
get {
return first;
}
}
Is actually more characters than the code that you did not want to repeat:
private HeavyObject first;
public HeavyObject First {
get {
if (first == null) first = new HeavyObject { MyProperty = Value };
return first;
}
}
Apart from that, I think that the implicit cast made the code very hard to understand. I would not have guessed that a method that simply returns first, actually end up creating a HeavyObject. I would at least have dropped the implicit conversion and returned first.Value from the property.
Don't do it at all.
Generally using this kind of lazy initialized properties is a valid design choice in one case: when SomeOperation(); is an expensive operation (in terms of I/O, like when it requires a DB hit, or computationally) AND when you are certain you will often NOT need to access it.
That said, by default you should go for eager initialization, and when profiler says it's your bottleneck, then change it to lazy initialization.
If you feel urge to create that kind of abstraction, it's a smell.
Surely you'd at least want the LazyPropery<T> to be a value type, otherwise you've added memory and GC pressure for every "lazily-loaded" property in your system.
Also, what about multiple-threaded scenarios? Consider two threads requesting the property at the same time. Without locking, you could potentially create two instances of the underlying property. To avoid locking in the common case, you would want to do a double-checked lock.
I prefer the first code, because a) it is such a common pattern with properties that I immediately understand it, and b) the point you raised: that there is no hidden magic that you have to go look up to understand where and when the value is being obtained.
I like the idea in that it is much less code and more elegant, but I would be very worried about the fact that it becomes hard to look at it and tell what is going on. The only way I would consider it is to have a convention for variables set using the "lazy" way, and also to comment anywhere it is used. Now there isn't going to be a compiler or anything that will enforce those rules, so still YMMV.
In the end, for me, decisions like this boil down to who is going to be looking at it and the quality of those programmers. If you can trust your fellow developers to use it right and comment well then go for it, but if not, you are better off doing it in a easily understood and followed way. /my 2cents
I don't think worrying about a developer not understanding is a good argument against doing something like this...
If you think that then you couldn't do anything for the fear of someone not understanding what you did
You could write a tutorial or something in a central repository, we have here a wiki for these kind of notes
Overall, I think it's a good implementation idea (not wanting to start a debate whether lazyloading is a good idea or not)
What I do in this case is I create a Visual Studio code snippet. I think that's what you really should do.
For example, when I create ASP.NET controls, I often times have data that gets stored in the ViewState a lot, so I created a code snippet like this:
public Type Value
{
get
{
if(ViewState["key"] == null)
ViewState["key"] = someDefaultValue;
return (Type)ViewState["key"];
}
set{ ViewState["key"] = value; }
}
This way, the code can be easily created with only a little work (defining the type, the key, the name, and the default value). It's reusable, but you don't have the disadvantage of a complex piece of code that other developers might not understand.
I like your solution as it is very clever but I don't think you win much by using it. Lazy loading a private field in a public property is definitely a place where code can be duplicated. However this has always struck me as a pattern to use rather than code that needs to be refactored into a common place.
Your approach may become a concern in the future if you do any serialization. Also it is more confusing initially to understand what you are doing with the custom type.
Overall I applaud your attempt and appreciate its cleverness but would suggest that you revert to your original solution for the reasons stated above.
Personally, I don't think the LazyProperty class as is offers enough value to justify using it especially considering the drawbacks using it for value types has (as Kent mentioned). If you needed other functionality (like making it multithreaded), it might be justified as a ThreadSafeLazyProperty class.
Regarding the implicit property, I like the "Value" property better. It's a little more typing, but a lot more clear to me.
I think this is an interesting idea. First I would recommend that you hide the Lazy Property from the calling code, You don't want to leak into your domain model that it is lazy. Which your doing with the implicit operator so keep that.
I like how you can use this approach to handle and abstract away the details of locking for example. If you do that then I think there is value and merit. If you do add locking watch out for the double lock pattern it's very easy to get it wrong.