Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I bet this question has been asked before, but I can't really find out what i'm looking for, so excuse me in advance :)
is there a difference (programmatically speaking OR overhead speaking) between this:
var data = GetProducts();
GetAllData(data);
and this:
GetAllData(GetProducts());
what are the pros and cons of both methods if any? is there a more elegant/right way of achieving it (say Func<>)?
thanks in advance,
Rotem
Doing it in two lines makes it easier to debug, because you can break on the second line and observe the value assigned on the first line.
The compiler will optimize them both into the same CIL anyway, so it's not a matter of efficiency. It's all a matter of preference.
There is no functional difference and when the code is translated into machine language (or JVM byte code or whatever), it will result in more or less the same low level code.
The main difference is a matter of (a) aesthetics and (b) maintainability of the code. With respect to aesthetics, some may argue that the second form is prettier. It's largely personal choice but I would argue that if the expression wasn't as simple as GetProducts() but was very long (e.g. GetContext().GetProductService().GetProductsFor(GetContext().GetCurrentUser()) then breaking it up into two lines with an intermediate variable is more readable.
With respect to maintainability, I think you will find that having fewer variables is always better for future maintenance. You are less likely to encounter bugs relating to side effects or changing assumptions. In other languages you can use constructs like const or final to use the compiler to help protect against code rot, but I would still argue that it's cleaner to have fewer lines of code.
Hope this helps!
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I have a c# method that runs certain code blocks in a certain order. I want to pass a boolean parameter : "IsRunningInReverse" that will reverse the order in which the code blocks are run?
I could just create 2 private methods that just call the statements in normal and reverse order but I'm wondering if there is a better way to accomplish this?
I was thinking about creating delegates (Action<>) and storing them in a List and then the boolean "IsRunningInReverse" would determine whether I'd run through the list in ascending or descending order but I don't know if that's the cleanest solution.
Any input would be greatly appreciated.
Thanks!
Your solution seems fine to me.
Using Actions would be an idiomatic modern C# object wrapper for delegates, you can manipulate them easily.
To put them into a list is simple and will allow for what you want (reverse order), and even more (arbitrarily reorder them)
Maybe what might be more complicated and deserves some consideration is : would you need shared data ?
It should not be too difficult to handle this, but you would need a bit more structure (design some data sharing class for instance.
If you want to go further, once you feel more at ease with your solution, is maybe learn about expression trees .
That would be a powerful tool to manipulate different operations / actions. Beware, though, there is a large learning gap, it is quite more complicated than a List of Actions. If you simple want to reverse operations, I would still deem your List<Action> idea much more clean because it is much more simple and readable. I just thought it was worth mentioning.
How I would do it:
Make your "steps" separate functions.
Make a dictionary of the tasks and the "rank".
Then just sort asc/desc depending on what you are after.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I was just wondering where there any downsides to using in method argument from c# 7.2
I know this is recommended for dealing with Structs and they say it won't increase performance that much but from what I can tell this won't have any negative impact on the code and might help you with stack overflow exceptions when doing recursions.
Dose anyone know of a good reason why all methods should not be marked as in?
I found why people recommend to avoid ref and out but they don't work here.
As this is a performance related question, as a matter of discussion in was introduced for that reason, it's hard to find single, correct answer, without really measuring performance on concrete code sample.
But...
We know that in creates a reference which is 32bit on x86 OS, and 64bit on x64 OS.
Now consider a structure like
struct Token
{
char x;
}
on x64 OS, copy this structure on the stack, likely, will execute faster, than creating 64bit reference to the same data.
Plus, do not forget, that in implies "constantness" on an instance, which goes beyond performance reasoning, and targets directly your design. Hence, while from performance related matters, some of reasoning might be arguable, from design point of view, in has distinct and clear semantics to target specific design use cases.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
In C#, how expensive it is to create a new class instance?
I'm speaking in context of using C# in unity3d. Meaning that stuff continuously gets called many times per second.
In C++, generally speaking (while making games) you may want to reuse anything you created with new/smart pointers, you would want to keep allocated resizeable buffers/lists/fifos and you may want to avoid that uses dynamic memory allocation (and stick to local variables) if code is getting performance critical.
So, what is the recommended way to do it in C#? Is it a very bad idea to create a new List, return it from the function and then "forget" about it, never using it again?
P.S. I'm aware of profiling and "premature optimizations", but I'd like to know some generic guidelines for the language before I (possibly) make a big mess because I used the wrong approach.
I remember reading a fun post Performance numbers in the pub by Ayendy Rahien.
How many CLR objects can you create in one second?
And here was the result back in 2011
Created 7,715,305 in 00:00:01
Jokes aside. Create is pretty cheap operation but GC is not. So while you can create really many objects, it is the collect that will hurt performance. So a rule of objects reuse can apply to C# as well.
I'd assume, but can be wrong, implementation of a new operator is located in JIT
aloc.h
aloc.cpp
As usual, avoid premature optimisation till you need it.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I am constructing a LINQ query on a DataSet, it will have a .Where condition, .Distinct and .OrderBy. I was thinking of doing this manually at first, at best I can probably manage this in two loops. Which method is faster? Is there anyway to see what LINQ does in the background?
Is there anyway to see what LINQ does in the background?
Well, you could look at my Edulinq implementation and the accompanying blog posts to get an idea of what's going on in LINQ to Objects. Obviously it's not the real implementation, but it will give you a good enough idea.
I would strongly suggest setting yourself some reasonable performance targets, implementing the code in the simplest possible way (which is almost certainly to use LINQ) and then seeing whether it meets your targets.
There are situations where hand-coding this sort of thing can bring significant improvements - but they're relatively rare, and you should only go for that after proving that it's worth it, IMO. LINQ is at least "pretty good" when used properly.
LINQ isn't about performance, it's about productivity. Building your own loops may result in a faster program, but unless you measure it, you wont know how much faster if at all.
On the other hand, you could probably write a Linq query in a fraction of the time spent writing the loops, and use the rest of that time optimizing the parts of the application that are slow and can be significantly improved.
Which is faster: me looking through a textbook page by page until I find the usages of a word I want, versus me asking someone else to look through the same textbook page by page looking for the usages, nudging me every time they do?
If you are concerned about performance, what is usually needed is a design change to accommodate that - for example, using the index.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
What are the ways to identify Syntactic Sugar? For example, if someone is unaware of the version 1.0 of C# and gets involved in learning version 4.0, how should he/she go about detecting Syntactic Sugar? Is looking into the disassembled code the only way?
OR
Should a guy learning C# 4.0 go all the way down to 1.0, peeling one layer of abstraction after the other, to see the inner details?
An example:
When dealing with Events in C#, the following comes to my mind (courtesy Hans Passant)
the += operator calls add(), -= calls remove()
P.S.
The questions I ask may be just too hilarious for the extremely knowledgeable crowd here. But making sense of the ever evolving software world is no "walk in the park". It is like finding your way out of the Amazon (I mean the Brazilian jungle. The website is easy to navigate.).
Everything atop electric current is syntactic sugar for us humans. The computer doesn't need that nor does the alphabet or words as we know them mean anything to him.
Your job as a programmer is to use whatever feature makes you job easier. There is no bad feature if it makes you faster or better. Preferably both.
You'll easily detect sugar going backwards from .NET 4.0 and noticing that simple "sugared" language structures from higher versions are getting more and more complicated.
Sugar is nothing bad, just need to know that there are many ways to accomplish certain task.