Re: How about this syntactic candy?

On 2007-11-24 18:39:31 -0800, "Steve Thackery" <nobody@xxxxxxxxxxx> said:

I agree with Arne. Do you actually *know* that list.Count gets evaluated each time and the end result is *actually* slower?

list.Count had _better_ get evaluated each time. There's nothing about C# that suggests that it should assume the value in the loop continue condition won't change. Unless the code in the loop is so simple that it is guaranteed that the list.Count property won't change during the execution of the loop, optimizing the expression to avoid reevaluating list.Count would be wrong.

I don't claim to know, but suspect there is a good chance the optimisation will sort it all out anyway. I once saw a demo of a for loop all compressed into one line with ingenious shortcuts and contractions, and after the optimising compiler had been through it, it generated EXACTLY the same machine code as an alternative loop written out in full.

There may be a situation where the compiler cannot tell that list.Count is constant, but where it actually is. In that case, I could see the utility in providing the compiler with an explicit statement to that effect, but it seems to me that the current method required is so easy and simple, I can't imagine the point in adding something extra to the language to support the behavior.

One thing I like very much about C# is its simplicity. I think people can get carried away trying to add all their favorite "syntactical sugar" to the language, weighing it down with all sorts of stuff that just makes things harder on the compiler, the spec writers, and the developers. Things that are added to the language should be _really_ important and provide some significant functionality. I don't think this example applies.

In fact, I vaguely remember someone explaining that code which is highly optimised by the writer can even make the optimising compiler produce *worse* code than a simple, but verbose, version of the algorithm. I can't remember the product, unfortunately. Could it have been an old Delphi?

I think that's a general truth, regardless of language. Optimizing compilers often can take advantage of commonly used code structures. If you write code that's "sneaky", where you've tried to create some optimization outside of the compiler, it's possible that the compiler could fail to be able to actually generate optimal code.

I would expect that to be a rare situation. Compiler technology has gotten extremely good. But I wouldn't rule it out.

The point is somewhat moot anyway. After all, you shouldn't be optimizing code that doesn't need optimizing anyway. Write it readable first, optimize if and when there's a specific performance issue that needs to be fixed.

I've always believed that optimising at the written code stage is:

1/ undesirable, because it makes the code much harder to understand, debug and maintain

2/ unlikely to work anyway

I agree. :)

Pete

.

Relevant Pages

  • Re: Letter to US Sen. Byron Dorgan re unpaid overtime
    ... >> considered to be a convenience by those who use the C language. ... I make no claims to being a VB.NET programmer. ... Ritchie SCREWED UP in designing the for loop because ... I do not believe that you are capable of writing a conforming C compiler. ...
    (comp.programming)
  • Re: Order of function evaluation
    ... The optimizer in the compiler is allowed ... This is a typical optimization in any compiled, imperative language. ... >There were compilers that would evaluate sqrtoutside the loop, ... Of course, in any programming language, the programmer can hoist ...
    (comp.lang.c)
  • Re: Order of function evaluation
    ... The optimizer in the compiler is allowed ... This is a typical optimization in any compiled, imperative language. ... >There were compilers that would evaluate sqrtoutside the loop, ... Of course, in any programming language, the programmer can hoist ...
    (comp.lang.fortran)
  • Re: Interesting article by Randall Hyde
    ... > restatement of a whileloop, ... then most optimizing C compilers are severely ... result that the compiler can determine at compile-time (assuming, ... I'm advocating that programmers take more ...
    (comp.lang.asm.x86)
  • Re: Article of interest: Python pros/cons for the enterprise
    ... Optimized C programs can crash when pointers walk off the ... Very rarely, say inside a loop, I temporarily change my default compiler ... because i might be aliased to something, but in a sane language it ...
    (comp.lang.python)
Loading