Hacker News Reader

Comment by michaelmrose | Hacker News Reader

> Sure, lines of code doesn’t correlate to how much actual code is produced, but I feel like that’s just being pedantic.

It is actually the core of the entire understanding. There is no mapping whatsoever lines of code and instructions executed. A finite program that doesn't halt will result in infinite instructions. Less pedantically a sorting function that is far more efficient will result in the instructions corresponding to individual operations being called thousands of times less.

Basically everything from function calls to loops ruins any mapping between brevity and execution time.

View on HN

Normally I don’t continue with arguments like this haha. But I just want to point out that I keep saying generally more code means a slower algorithm. And when I say slower algorithm, that implies I’m comparing it to something. The thing I’m comparing it to is an equivalent algorithm with less lines of code. An infinite loop will run forever with just a few instructions. But I’m not comparing an infinite loop to anything here.

And just to be clear, I do agree with everything you’re saying here, but I do think you’re still being overly pedantic.

> Less pedantically a sorting function that is far more efficient will result in the instructions corresponding to individual operations being called thousands of times less.

Exactly. The goal is to spend fewer instructions to achieve the same outcome. As soon as you start thinking about how different instructions take different amounts of cycles and you can speed up an algorithm by using more instructions that are cheaper, that kind of proves my whole point. You can speed up an algorithm by using more instructions, but you have to be intentional about it. The default will never be: more instructions = faster.

If you mean to say that on average, if you sample from a distribution of randomly-assembled instructions, then code with more lines will run longer, then that's fair. However, I don't think that most code is randomly-assembled, so sampling from that distribution doesn't make realistic sense to me.

Basically,

> You can speed up an algorithm by using more instructions, but you have to be intentional about it.

I feel like most code is written with some intention. It depends on whether or not you believe that most code is written competently, I guess.

It doesn't matter whether it's written competently. The original debate was about lines of code. There is no mapping between lines of code and instructions executed because loops and conditionals are a thing. EG even if 20 lines of code results in twice as many instructions as 10 it tells you absolutely nothing about how many times each instruction will be executed and ergo nothing about the clock time required to execute the program.

Reply on news.ycombinator.com