Indeed it should never be spelled wrong, as it means in itself in latin, my bad really.

Alt rows are a simple concept, the first row is odd, the next is even, etc.

A good step forward is an if/then/else or a switch or an unrolled loop - a huge step forward in terms of performance too, as a mod takes 63 cycles and a cmp takes almost nothing.

an example could be

rowClass='even'; loop if(rowClass=='odd'){ rowClass='even'; }else{ rowClass='odd'; } endloop

Unrolling loops is premature optimization, and we all should know what that is the equivalent of.

Unroll your loop once they are tried, tested, and working correctly, and a profiler finds out you spend much too time in the specific parts that would be discarded when unrolling.

The liberties you took with your pseudocode above prove the point: as others have noted, you've chosen premature optimization over using a fitting data type. The first could be easily fixed before release. The latter is harder.

I think I must be misreading you. Are you suggesting doing a string comparison to avoid the performance hit of a mod?

I did write it like that yes.

And it would still be faster than a mod, too, even though one byte might be better for registry usage, it won't affect cycles that much iirc.

Hey, guess what? You're wrong. (at least in python, which is a reasonable guess for a language that's generating html)

    >>> import timeit
    >>> timeit.Timer(stmt="z=101%2").timeit()
    0.033080740708665485
    >>> timeit.Timer(stmt="z='even'=='odd'").timeit()
    0.05949918215862482

It does seem to be true for javascript though:

  > profile = function(fn) { var start = Date.now(); fn(); return Date.now() - start; }
  > cmp = function() { for (var i=0; i < 1000000000; i++) { var z = 'odd' === 'even'; } }
  > mod = function() { for (var i=0; i < 1000000000; i++) { var z = 101 % 2; } }
  > prof(cmp)
  20329
  > prof(mod)
  40792

Whether you think those 20 nanoseconds per test are worth saving is, I guess, an open question. :) I can imagine it being useful for game programming, for example.

If you know there are only two states, why not have a bool that you flip each time?

is_even = !is_even should be a lot cheaper than string comparison or modulus, assuming a reasonable language.

I love fairy tail Indeed you can do much better, flipping boolean + cmp if you only need two states, and integer + array if you need three or more - main thing is, even the "stupid" string comparison is much cheaper than a modulus, and it's a very logical basic approach that says " if the previous row was odd, this one must be even ".

My idea with that is that it's extremely important to reach that conclusion, as it matches the problem perfectly and thus is much more efficient than our (often natural) standard approach of mod(x,2).

When you've reached that step, you can further improve by using a boolean instead of a short string, but that steps clearly into optimization, as it's not "formulating the problem correctly" but "finding a better way to implement the same solution".

There is major cost in not formulating the problem correctly (even odd is an approach to alternating colors, not the problem itself), and mod for table rows is a prime example of that.

> Some approaches are NOT acceptable, it's not about optimizing prematurely, it's about coding obvious crap.

And yet we miss the simple, efficient answer?

    isEven = 1
    rowClasses[] = { 'odd', 'even' }
    loop
        isEven = 1 - isEven
        rowClass = rowClasses[isEven]
    endloop

It might only be an example but if you're going to complain about people's inefficient/wrong code, the least you can do is provide a good demonstration.

As I said above, that's a better implementation of the same solution which is, pick two states and alternate by using the knowledge that if the previous is odd the next is even.

In essence your solution and the strcmp one follow the same logic, except yours is limited to two states as it is - but indeed the best n-state solution uses an array too.

What you posted here is a somewhat optimized implementation of the right solution, which is slightly better, like the boolean one (indeed you're using one bit that you flip ...).

But the BIG difference between the mod family of solutions and ours is that mod is over ten times slower because it does not correctly use the problem data.

I'm not the best coder there is, but I know it is much simpler to base yourself on something you already know (the state of the previous row) rather than doing additional computing because an analytical approach says alternating two colors is like having a color for even rows and one for odds.

By the way. your code is evil, if you're going to implement two-state logic, you're expected to use a boolean, and it will run faster with an if(b){str1}else{str2} than with an array that costs additional processing because of its nature (I'm talking straight out of my ass btw, but I still know it's inevitable that an array of two strings requires more bits and ops than two strings).

Also, the point of using an array for such an exercise would be to support n-state logic, yet your fake-boolean int approach makes it doubtful ;)

> faster with an if(b){str1}else{str2}

I'm not aware of any compiler that optimises such a structure to avoid branch misprediction. An array of two strings might require more bits and ops in an unoptimised interpreted language, or one in which bounds checking is always enabled, but I can assure you that an indexed load is 1 instruction and a load for each string is... well, more than that. You are right, you are definitely talking straight out of your ass!

The n-state solution is a state machine, btw - but it is right to use a simple solution if that is all your problem requires.

For 99% of code, worrying about the number of cycles in an operation is an utter waste of time. It just doesn't matter. Correctness and readability trump machine efficiency.

Do you work on real-time systems, embedded code, or something similar?

You are repeating a point of view you do not understand.

You don't know WHY people started saying that, WHEN they started and WHO started.

It was started by old people a while ago who told even older people that for the simple stuff they were writing for DESKTOP computers, it didn't matter anymore.

Indeed, if you have a 486dx4 and all you want to do is word processing, it didn't matter much wether it was optimized or microsoft word as the thing was way too powerful for that kind of stuff already.

Today, battery life is a concern, virtualization is a reality, scalability is a CORE issue, there are low power states etc.

Today, making your application 100 times more efficient gives you 10x more battery life,100x lower cloud hosting costs, 100x better scalability, etc.

Think that's unlikely ? You've been stacking inefficient blocks for a lifetime, sometimes with inefficiencies multiplying, where do you think you are today ?

Simple example, from a pgsql>jdbc>jboss>j2ee>hibernate>java report factory to a dumb php script that did simple SQL, you already have factors above 20 in favor of the simple solution.

That's before you make a better data model or even try using a fast language or a more suiting data store depending on your needs.

Besides, your argument is nonsense, the simplest most correct way IS the most efficient, that's the power of programming, there is absolutely NO compromise between reliability and efficiency in terms of code.

Readability is over rated, as long as you don't code crap, any COMPETENT coder will be able to read and understand fast enough, even without comments.

Do you work on overweight UIs that drain phone batteries or cloud-hosted applications or anything that needs scaling ?