[FooBarWidget]

Abstractions are not necessarily slow. The BSD socket API is an abstraction over sending raw TCP/IP packets to your Ethernet card, but you're not going to get a whole lot more performance out of accessing your Ethernet card directly.

[ikeepforgetting]

Well, they're always slower than not having them. Having a few layers on top of each other starts to add up. It's very easy to lose track of the bottlenecks of 2 or more layers below the one you're working in. There is a reason HTTP.sys runs in kernel space and BSD sockets don't. And there's a reason both of them are slower than XMLHttpRequests.

PS. The fact that you can point to one (or a few) efficient abstractions doesn't mean they all are.

[taeric]

Just no. Some abstractions are light years faster than not having them. To the point that this is a silly statement. Consider the elementary abstraction of an array. The slightly less elementary one of a map.

More close to heart, the abstraction that source control gives you. Imagine not having git (or whatever tool) and thinking you will compare this weeks code with what was available last week. Now just do the same based on the changes introduced by a single developer. Trivial with the abstraction of source control. Hella tough without.

So, no, just because there are layers of abstractions does not automatically mean things are going to be slow.

All of that said, I can see and ultimately agree with your point. Excessive abstraction can be bad. Unfortunately, I think the jury is out on where the hell that line is. (Likely they are distracted with other pointless questions while others are out solving problems.)

[iforgotagain]

>> Just no. Some abstractions are light years faster than not having them. To the point that this is a silly statement. Consider the elementary abstraction of an array. The slightly less elementary one of a map.

Abstractions can definitely be an improvident in some cases. They just bring extra complexity at it's cost. In the 'map' case you pointed out, you now need to take into account the performance characteristics of an array, one or more hash functions and linked lists in their specific configuration.

Even though the lookup of a hashmap is supposed to be O(1), you now have to run a hash function for every lookup. That's bound to be slower than the simple integer addition we were doing before on the flat array.

Besides that, if it's a bad hash function (or if the data is bad), performance will easily go down to O(n).

>> So, no, just because there are layers of abstractions does not automatically mean things are going to be slow.

That's not what I'm saying is it? I'm making the point that it'll be slow/er/ because of the overhead of the abstraction. I didn't say "less productive" or "every abstraction is bad", I'm point out that each extra layer comes at a cost and that the extra cost gets buried the more layers you add.

I'm not going to go into the source control argument because I'm talking runtime application performance and mental overhead, not developer performance.

[taeric]

But that is my point, if used correctly, the abstraction just makes it easier to do what you want to do quickly. Consider, math is basically abstracting away the tedious nature of some physical process. I mean, if you know it takes 2 eggs to make 4 waffles, and want to make 82 waffles, the abstraction of math makes this much quicker than just doing it to determine how many eggs you need.

Basically, I object to the idea that abstractions slow you down by their nature. I agree that poor or unnecessary ones do so.