Using IEnumerable nonsense for everything
-
I would be a bit surprised if your first point was true. Please give me a couple examples of optimizations that depend on function size.
Mike Marynowski wrote:
I would be a bit surprised if your first point was true. Please give me a couple examples of optimizations that depend on function size.
Small functions can be in-lined by the optimiser, so this code
foreach(string x in y)
{
x = x.Trim().ToLower();
DoSomething (x);
}function DoSomething(string s)
{
if (s.StartsWith("hello"))
{
s = "test";
}
}might be optimised to this
foreach(string x in y)
{
x = x.Trim().ToLower();
if (x.StartsWith("hello"))
{
x = "test";
}
}thus avoiding a code jump\stack update etc.
-
Mike Marynowski wrote:
I would be a bit surprised if your first point was true. Please give me a couple examples of optimizations that depend on function size.
Small functions can be in-lined by the optimiser, so this code
foreach(string x in y)
{
x = x.Trim().ToLower();
DoSomething (x);
}function DoSomething(string s)
{
if (s.StartsWith("hello"))
{
s = "test";
}
}might be optimised to this
foreach(string x in y)
{
x = x.Trim().ToLower();
if (x.StartsWith("hello"))
{
x = "test";
}
}thus avoiding a code jump\stack update etc.
Yes, but that optimization doesn't have to be made if you are putting everything into a big block of code lol. I'm not advocating for that approach, just saying that splitting into functions is unlikely to boost performance...in the best case it will match performance after optimizations, which is basically what is happening in this example.
-
But you agree it wouldn't be immediately obvious like it would if you weren't using linq?
If I wasn't using LINQ, then I'd be able to identify which line in the massive complicated method the exception was thrown from. Whether it would be obvious why the exception was thrown is a different matter. :)
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
If I wasn't using LINQ, then I'd be able to identify which line in the massive complicated method the exception was thrown from. Whether it would be obvious why the exception was thrown is a different matter. :)
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
So it's easier to debug without linq? :)
No, because you've still got a massive overly-complicated method to dig through to find the cause of the problem. :)
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
Richard Deeming wrote:
Writing all of your code in one big
Mainfunction is faster than any of this "object-oriented" nonsense.That is, almost certainly, not true. With one big function, the optimizer will have to practically shut-down. Many smaller functions can be highly optimized.
Richard Deeming wrote:
And using C or assembly will be much faster than this JIT-compiled C# nonsense.
Again, real world examples have shown that letting the computer do things like managing your resources, is much faster than trying to do it yourself manually.
Truth, James
I think I need to buy one of those "sarcasm" flags. :-D
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
No, because you've still got a massive overly-complicated method to dig through to find the cause of the problem. :)
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
You instantly know the code that threw the error though so that's a big starting point. Let me give you a better example
string mytext = mydata.Where(a => a.Name != "Admin" && a.ID < 1000).OrderBy(b => b.Surname).SelectMany(c => c.Role).FisrOrDefault(d => d.Updated.Year == DateTime.Now.Year);
We've all seen code like this, right? Let's say it throws a null exception, good luck finding out what is null. If you split your code into functions\loops you don't have that issue.
-
You instantly know the code that threw the error though so that's a big starting point. Let me give you a better example
string mytext = mydata.Where(a => a.Name != "Admin" && a.ID < 1000).OrderBy(b => b.Surname).SelectMany(c => c.Role).FisrOrDefault(d => d.Updated.Year == DateTime.Now.Year);
We've all seen code like this, right? Let's say it throws a null exception, good luck finding out what is null. If you split your code into functions\loops you don't have that issue.
Start by changing the code to:
string mytext = mydata
.Where(a => a.Name != "Admin" && a.ID < 1000)
.OrderBy(b => b.Surname)
.SelectMany(c => c.Role)
.FirstOrDefault(d => d.Updated.Year == DateTime.Now.Year);Your stack trace will include a line number, which will tell you exactly which line you need to look at. :)
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
Start by changing the code to:
string mytext = mydata
.Where(a => a.Name != "Admin" && a.ID < 1000)
.OrderBy(b => b.Surname)
.SelectMany(c => c.Role)
.FirstOrDefault(d => d.Updated.Year == DateTime.Now.Year);Your stack trace will include a line number, which will tell you exactly which line you need to look at. :)
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Guess null exceptions aren't a particularly great example of debugging, despite what you might read on CP they're not the hardest issues to track down. When it comes to logic issues with streams of chained linq statements if you want to debug them to find out better why you're getting\not getting the results you want you often have to isolate the steps and loop at them in-turn which is an additional faff you wouldn't have otherwise.
-
Guess null exceptions aren't a particularly great example of debugging, despite what you might read on CP they're not the hardest issues to track down. When it comes to logic issues with streams of chained linq statements if you want to debug them to find out better why you're getting\not getting the results you want you often have to isolate the steps and loop at them in-turn which is an additional faff you wouldn't have otherwise.
I still think that's easier to do if you're reusing small methods that do one clearly-defined thing, and which have been thoroughly tested, than if you've lumped all of the implementation into one giant method. :)
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
I still think that's easier to do if you're reusing small methods that do one clearly-defined thing, and which have been thoroughly tested, than if you've lumped all of the implementation into one giant method. :)
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Regardless, debugging is still harder with chains of linq statements, that's the only point I was making.
-
That might be true but it comes at the cost of jumps and stack management for function calls. I think you will be hard-pressed to find an example of one block of code that runs slower than similar code split into more functions.
But then, what about library functions? Are you going to inline every call to ToUpper() or Trim()? If you do, you have a unmanageable mess. If you don't, then you're back to the costs of jumps and stack management, so what's a few more?
Truth, James
-
Linq => Backward SQL
We're philosophical about power outages here. A.C. come, A.C. go.
Actually, I think of it as SQL the right way round. A good clue comes from intellisense. It cannot get the field names unless you write the FROM before the SELECT.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
But then, what about library functions? Are you going to inline every call to ToUpper() or Trim()? If you do, you have a unmanageable mess. If you don't, then you're back to the costs of jumps and stack management, so what's a few more?
Truth, James
"What's a few more" is often significant overhead. I don't know what argument you think I'm making. The comment that is the topic of my comments simply said that writing your code in a big main function is faster that all this object oriented stuff but probably a bad idea. I'm agreeing with that.
-
BillWoodruff wrote:
I get a glimpse of your shadow going around a corner
You are generous as always! There are some corners I probably should not be followed:
public static bool If(this bool b, Action action)
public static void IfElse(this bool b, Action ifTrue, Action ifFalse)
etc. Let's just call those "experiments." :) Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Is that a Smalltalk influence I detect? In Smalltalk, there are no control flow statements beyond sending messages. However, the boolean object responds to the messages ifTrue: and ifTrue:Else:
(x < 3) ifTrue: [ x <- 3 ].
(x < 3) ifTrue: [ x <- 3 ] Else: [ x <- x + 1 ].And of course similar constructs such as:
(x > 0) whileTrue: [ x <- x - 1 ].
Here [] denotes a block of code (similar to a closure) and <- denotes assignment.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
The newest thing? It has been around for almost 10 years... :~ The paradigm itself, readable, no side-effects code making heavy use of lambda's (or anonymous function) has been around almost as long as programming. It's called functional programming.
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
As LISP came out in 1958, it makes it a pretty old thing for programming. Venerable even.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
