[nijaar]

if it is smaller, doesn't it mean that it has less code to execute hence should it be faster? Trying to understand better -- this is something completely new for me

[duped]

Not necessarily, in fact one of the most important optimizations for compilers is inlining code (copy-pasting function bodies into call sites) which results in more code being generated (more space) but faster wallclock times (more speed). Most optimizations tradeoff size for speed in some way, and compilers have flags to control it (eg -Os vs -O3 tells most C compilers to optimize for size instead of speed).

Where optimizing for size is optimizing for speed is when it's faster (in terms of wall clock time) for a program to compute data than to read it from memory, disk, i/o etc, because i/o bandwidth is generally much slower than execution bandwidth. That means the processor does more work, but it takes less time because it's not waiting for data to load through the cache or memory.

[nijaar]

great explanation. thank you!

[josephg]

Why would a program run faster just because it’s smaller?

[FullyFunctional]

Example: this is a small program

int main() { for(;;); }

[josephg]

Oh, I suppose I’m imagining two implementations that both do the same work. (Like two rust compilers).

Eg, quicksort vs bubble sort. Quicksort is usually more code but faster.

Or a linked list vs a btree. The linked list is less code, but the btree will be faster.

Or substring search, with or without simd. The simd version will be longer and more complex, but run faster.

Even in a for loop - if the compiler unrolls the loop, it takes up more code but often runs faster.

If you have two programs that both do the same work, and one is short and simple, I don’t think that tells you much about which will run faster.