2

I'm honestly not that I would address this problem at all within my own courses, but if it is to be faced, I suspect that the solution would be something like this: Immerse students in their current layer. Really teach the metaphor and thought-process of the layer that they are currently in, and only accept code that utilizes that model of thinking. Warn ...


2

The way that everyone generally learns this lesson is to spend a significant amount of time tracking down an efficiency issue that is nowhere near where you expected it to be. I'm not sure there's another way to really learn the lesson. As an example, here's an exercise which illustrates the problem: Write an implementation of an open-addressing hash table ...


1

It might be helpful to use a tool such as Compiler Explorer. It allows one to put side by side C code and its compiled version. It can be used to show that the compiler often generates the same assembly code for the "naive" code and the hand "optimized" one. It also supports compiler flags, so you could use it to show the difference between unoptimized code ...


Only top voted, non community-wiki answers of a minimum length are eligible