By efficient I meant it achieves the same result with less cost, not that it minimizes electricity waste. If distributed solar "will also reduce the size of the economy", doesn't that mean it's more efficient?
It's hard to argue that inefficiency is good for the economy. In fact, proponents of alternative macroeconomic metrics cite the GDP's bias against efficient renewable energy as one of its flaws [1].
If you pursue a bigger economy without considering efficiency and the societal benefits of other labor/capital allocations, you run the risk of prescribing bad policies. E.g., a government can grow GDP just by hiring idle workers to dig ditches one day and fill them back in the next.
[1] de Graaf and Batker. What's the Economy For, Anyway?
> going to Basecamp, the entire time waiting in chrome ... is between 150-200ms
The numbers in my comment are "without caching". Comparing them to Basecamp, which caches views and fragments heavily, is apples to oranges. Once I add caching, my typical response times for a cache hit are in the 10s of milliseconds.
You made an Amdahl's law argument that view caching is fruitless because rendering is an insignificant part of total response time. So I responded with uncached performance to show why Rails needs view caching.
It's no accident that Rails has comprehensive caching support; that the Rails team has worked hard to refine and optimize caching in each release; and that DHH writes about it so often (including in this article). You can't have performant Rails without view caching because rendering is dog slow.
My Rails CRUD experience is the opposite. Template rendering always dominates database time. Without caching, rendering templates with nested partials is generally 5-10x slower than data access. Typical times are 20-50ms for ActiveRecord, 100-300ms for views. This is in production environments with production databases, Rails 2-4, even with alternative template engines that optimize for speed.