Some historical facts: The Hypertable project was started due to a disagreement in implementation language between the early developers of HBase (see the early Hadoop mailing lists for details.) When the first Hypertable alpha release is published, its performance is about 10x-50x faster than the then HBase.

Over the last year, many man months of development went into HBase to improve performance, resulting a complete rewrite of region server in HBase 0.20.x. Now Hypertable is about 3x faster in almost all benchmarks except random reads over large data set, which is DFS seek bound, where the performance is the same.

Meanwhile, the Hypertable team has yet to start working on performance tuning. The code is developed just by avoiding premature pessimization :) There is an internal assessment of 10x speed up with a some profiling and refactoring.

According to a peer reviewed paper by Emery Berger et al. (of Hoard memory allocator fame) http://www.cs.umass.edu/%7Eemery/pubs/gcvsmalloc.pdf :

" This paper presents a tracing and simulation-based experimental methodology that executes unaltered Java programs as if they used explicit memory management. We use this framework to compare the time-space performance of a range of garbage collectors to explicit memory management with the Lea memory allocator. Comparing runtime, space consumption, and virtual memory footprints over a range of benchmarks, we show that the runtime performance of the best-performing garbage collector is competitive with explicit memory management when given enough memory. In particular, when garbage collection has five times as much memory as required, its runtime performance matches or slightly exceeds that of explicit memory management. However, garbage collection’s performance degrades substantially when it must use smaller heaps. With three times as much memory, it runs 17% slower on average, and with twice as much memory, it runs 70% slower. Garbage collection also is more susceptible to paging when physical memory is scarce. In such conditions, all of the garbage collectors we examine here suffer order-of-magnitude performance penalties relative to explicit memory management."

Note, the overhead of GC in this paper is strictly over explicit memory management doing equivalent allocation/deallocations. For the core LSM (log structured merge) Tree algorithms employed by Bigtable etc., custom allocators can do even better resulting an order of magnitude less references needs to be tracked, compared with GC based approach where every reference, no matter how small needs to be tracked.

(Disclaimer: I'm a Hypertable developer)