(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)
Wednesday, June 14, 2006
Abstraction is a Bear
Peter Thomas has posted a very nice call stack showing how much of the run-time complexity of a typical J2EE operation is consumed by the framework and how little is consumed by the actual business logic. There's an awful lot of noise.
The comments are worth a read. I find the comments about how the JIT will rescue us from ourselves very interesting. I helped create an interesting product called JProbe, and we spent an awful lot of time thinking about server-side Java performance.
It is absolutely not true that inlining everything in sight makes the cost of indirection go away. It's true that it makes the cost of a method call go away. That's very expensive, and worth eliminating. [I'm curious: why does the Blub crowd appreciate the importance of inlining method calls to eliminate the cost of stack allocation, but dismiss tail call optimization as unimportant?]
However, indirection has another cost. When you have a reference to a reference to a reference to a reference to something you want, fetching the something at the end of the chain usually causes page faults. You have to do "pointer chasing." That is very expensive. Although that is not directly related to the number of framework elements in the call stack, I find that highly abstract frameworks seem to have a great deal of run time indirection built in, and that's also expensive.
Now, here's what I find very interesting: as seen in the comments, many developers shrug all this off as irrelevant given the network latency and relative sluggishness of the persistence engine. Given limited development time in many real-world projects, this may be an appropriate attitude to take.
It brings to mind a joke about two hikers:
Peter Thomas has posted a very nice call stack showing how much of the run-time complexity of a typical J2EE operation is consumed by the framework and how little is consumed by the actual business logic. There's an awful lot of noise.
The comments are worth a read. I find the comments about how the JIT will rescue us from ourselves very interesting. I helped create an interesting product called JProbe, and we spent an awful lot of time thinking about server-side Java performance.
It is absolutely not true that inlining everything in sight makes the cost of indirection go away. It's true that it makes the cost of a method call go away. That's very expensive, and worth eliminating. [I'm curious: why does the Blub crowd appreciate the importance of inlining method calls to eliminate the cost of stack allocation, but dismiss tail call optimization as unimportant?]
However, indirection has another cost. When you have a reference to a reference to a reference to a reference to something you want, fetching the something at the end of the chain usually causes page faults. You have to do "pointer chasing." That is very expensive. Although that is not directly related to the number of framework elements in the call stack, I find that highly abstract frameworks seem to have a great deal of run time indirection built in, and that's also expensive.
Now, here's what I find very interesting: as seen in the comments, many developers shrug all this off as irrelevant given the network latency and relative sluggishness of the persistence engine. Given limited development time in many real-world projects, this may be an appropriate attitude to take.
It brings to mind a joke about two hikers:
Two hikers are surprised by an aggressive bear. One turns to run away. "What are you doing?" asks the other, "you can't outrun a bear!" The hiker carries on and sprints away. "I don't have to outrun the bear," are the hiker's only words, "I just have to out-run you."(via Joey DaVilla. The post, that is. Don't blame him for the joke.)
Comments on “Abstraction is a Bear”:
<< Home
Blub programmers don't care about tail-call optimization because they write iterative -- not recursive -- functions.
Blub programmers don't care about tail-call optimization because they write iterative -- not recursive -- functions.
Yes, and thus the looks of bewilderment when they need to work with recursive data structures.
Yes, and thus the looks of bewilderment when they need to work with recursive data structures.
Weeding through huge stack traces to find bugs eats up a lot of my bandwidth.
CPU and memory are the least of my concern.
CPU and memory are the least of my concern.
<< Home
