On Thu, Mar 28, 2013 at 3:02 PM, Dan Kennedy <[email protected]> wrote: > So sqlite4 is using more CPU. But in this particular case is faster > overall because the way the database file is written is more efficient > (i.e. more sequential). It's probably writing a bit less too. > > One way to reduce the (perceived) CPU usage with sqlite4 is to move > segment merges (database work) and database syncs (database checkpoints) > to a background thread or process. Maybe we should have some way to > make doing that easy for applications. More detail in the following, > especially 6.1 and 6.3: > > http://www.sqlite.org/src4/doc/trunk/www/lsmusr.wiki#performance_tuning
Question: would it be better to optimize key and value encodings more for CPU and less for space? Space is still trending cheaper, but key and value encoding are very serial[0] and serial CPU performance is not likely to improve much more. Therefore it seems better to optimize for speed than for space. And I'd say this is true even for mobile devices, where storage capacities will probably keep increasing (at no additional cost in power) while CPUs are particularly bound by power consumption. Of course, mobile apps aren't likely to suffer much from key/value encoding being slow (lots of other things will be slower), but still. A counter-argument would be that optimizing for space is optimizing for I/O, but with random I/O getting faster (SSDs) I'm not sure that the trade-off is justified. Which brings me to: have you done enough profiling? I don't mean to presume that you haven't! If you can share your results that'd be great. [0] Well, for each column value the encoding is very serial. For multiple columns the whole encoding may be highly parallelizable in theory, but I'm betting that in practice it's not, so let's score the whole thing as embarrassingly serial. Nico -- _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
