link list

Erik: You still haven't realized that a linked list will (yes not may, but WILL) consume less CPU cycles for some tasks than a vector of pointers or a vector of entries. That is efficient.

That is also an absolute truth. Nothing relative about it. You just can not beat a linked list for some problems. You may not even be able to match it.

But on to another comparison: The car who is the fastest is not always efficient. Some of the fastest racing drivers never makes it to the finish because they are so fast that they fail to turn or break. That is not efficient, even if it is fast.

That a vector algorithm can consume less CPU cycles per iteration does not matter if the vector algorithm needs to do log(n) or n more iterations than a slower algorithm. Such a concept is brutally fast (per step), but brutally stupid - and brutally inefficient and in the end slow! Efficient is time from start to finish, not how fast you can run in circles moving around vector data.

An efficient algorithm almost always wins over efficient code. And a linked list is quite often an efficient method, just as a vector is quite often an inefficient method.

So that means that whenever someone is about to use a vector, you should warn them that they are about to do something inefficient. Using a vector where it shouldn't may result in a need to buy a faster processor, since all the copying (even if just pointers) consumes more bandwidth than the processor can manage - even if DMA is used where applicable. Definitely inefficient!

Switching to assembler wont help either. Wrong algorithm in assembler will loose to the correct algorithm implemented in interpreted basic, when n gets large enough. Donald E. Knuth wouldn't have written all his books about algorithms if that wasn't a fact.

Right now, you are basically warning every carpenter that whenever they pick up a screwdriver (electric or manual) they are inefficient, since they are not using a Hilti nail gun. But it doesn't matter how good a Hilti is to shoot in nails, if the target material breaks. That's fast but inefficient, and the result of using the wrong tool.

Insert to front takes one time (varying for different abstract data types).
Insert at the end takes another time.
So does searching for a random element.
So does sorting.
So does removing from head or tail.
So does iterating forward.
So does iterating backward.

But since a program is never only using one of the above operations, efficiency realy is relative. It is relative to the expected mix of operations. Most of the time, there will not be an absolute efficiency, since there will not be an absolute number of the different operations. As a developer, you have to make guesses how a program/unit will be used. But the absolute time for one iteration step of any of the above cases is totally irrelevant to the final product, since the end result depends on the sum of all iteration steps multiplied by the individual iteration times. Amd fast but stupid often looses.

Erik: You still haven't realized that a linked list will (yes not may, but WILL) consume less CPU cycles for some tasks than a vector of pointers or a vector of entries. That is efficient.

That is also an absolute truth. Nothing relative about it. You just can not beat a linked list for some problems. You may not even be able to match it.

But on to another comparison: The car who is the fastest is not always efficient. Some of the fastest racing drivers never makes it to the finish because they are so fast that they fail to turn or break. That is not efficient, even if it is fast.

That a vector algorithm can consume less CPU cycles per iteration does not matter if the vector algorithm needs to do log(n) or n more iterations than a slower algorithm. Such a concept is brutally fast (per step), but brutally stupid - and brutally inefficient and in the end slow! Efficient is time from start to finish, not how fast you can run in circles moving around vector data.

An efficient algorithm almost always wins over efficient code. And a linked list is quite often an efficient method, just as a vector is quite often an inefficient method.

So that means that whenever someone is about to use a vector, you should warn them that they are about to do something inefficient. Using a vector where it shouldn't may result in a need to buy a faster processor, since all the copying (even if just pointers) consumes more bandwidth than the processor can manage - even if DMA is used where applicable. Definitely inefficient!

Switching to assembler wont help either. Wrong algorithm in assembler will loose to the correct algorithm implemented in interpreted basic, when n gets large enough. Donald E. Knuth wouldn't have written all his books about algorithms if that wasn't a fact.

Right now, you are basically warning every carpenter that whenever they pick up a screwdriver (electric or manual) they are inefficient, since they are not using a Hilti nail gun. But it doesn't matter how good a Hilti is to shoot in nails, if the target material breaks. That's fast but inefficient, and the result of using the wrong tool.

Insert to front takes one time (varying for different abstract data types).
Insert at the end takes another time.
So does searching for a random element.
So does sorting.
So does removing from head or tail.
So does iterating forward.
So does iterating backward.

But since a program is never only using one of the above operations, efficiency realy is relative. It is relative to the expected mix of operations. Most of the time, there will not be an absolute efficiency, since there will not be an absolute number of the different operations. As a developer, you have to make guesses how a program/unit will be used. But the absolute time for one iteration step of any of the above cases is totally irrelevant to the final product, since the end result depends on the sum of all iteration steps multiplied by the individual iteration times. Amd fast but stupid often looses.