I can promise you it is not a matter of not being interested in performance enhancements, but there is a trade off between stability, backwards comparability, etc. Some of the changes you are proposing have merit but they fundamentally change some decisions that have been made and Jonathan needs to weigh those tradeoffs for the project.
Most importantly, Id file a bug with your proposed patches and have a positive discussion there. Best, Michael On Feb 22, 2013, at 4:04 AM, "Radim Kolar" <h...@filez.com> wrote: > Dne 13.2.2013 16:32, Jonathan Ellis napsal(a): >> The only point here that would make a difference in practice is >> leveldb using a worse hash function. > how do you know that it would not make difference in practice. i have > implemented some optimalization from leveldb to cassandra - different L0 > level - 12 tables of 1/10 size L1, faster promotion to next level and > variable number of sstables per level and it performs faster for write > heavy workload. > > i do not understand why you are not interested in performance > optimalizations. For example yesterday i did buffered sstable writing > and it turned to be significant perfomance advantage using 1mb buffer > changed test time from 1m50s to 0m40s. Another significant gain is to > use read ahead in compactions and replace bucket based size tiered > compaction to compaction strategy used in lucene - it did not produce > immortal sstables like cassandra does. > > i have quite high demands for perfomance, my test environment for new > project has about 1 bilion new rows per day, in production it will be > about 30 times higher, so what is worth coding for me might not be worth > coding for you. Copy, by Barracuda, helps you store, protect, and share all your amazing things. Start today: www.copy.com.
