On the different note, I am having about 1000 connection to the same SQLite data and as expected, it will be slower. What would be an efficient way to make it fast? I am opening dataset as Read Only.
Thanks Gaurav On Fri, Nov 25, 2011 at 4:52 PM, Jay A. Kreibich <j...@kreibi.ch> wrote: > On Thu, Nov 24, 2011 at 05:22:38PM +0000, Simon Slavin scratched on the > wall: > > On 24 Nov 2011, at 5:10pm, Jay A. Kreibich wrote: > > > On Thu, Nov 24, 2011 at 08:08:12AM +0000, Simon Slavin scratched on > the wall: > > > > > >> It is faster to search integers than it is to search real numbers. > > > > > > Why? Both types are a string of 64 bits. Both types use the same > > > integer-based logic for the =, <, and > operations. > > > > > > The only real difference is that integers are stored in a compressed > > > format. While that means they have a higher CPU cost to decode, the > > > smaller size likely makes up for the encoding overhead with improved > > > I/O times. I'm not sure there is a strong practical win, however-- > > > especially if the data is in cache, or doesn't span several pages. > > > > Hmm. I really should check this out with SQLite. It is generally > > true in computing. > > FP mathematics instructions (such as + - * / ) typically take many > more CPU cycles to complete than their integer equivalents. > > However, when it comes to comparisons (such as = < <= >= > ) you > might use in an index scan, the IEEE 754 standard is specifically > designed so that these operations can be done with the exact same > logic as unsigned integer numbers. In most CPUs the floating-point > pipeline has its own logic units to perform these operations (due > to the separation of integer and FP registers), but the speed of these > logic units should be the same as the primary integer units. > > > It may not be true given how SQLite uses different > > numbers of bytes to store different sized integers. > > Yes-- the variable length integers means there are extra decoding > steps for the integers. However, the variable length also means one > can, in theory, stuff more "typical" integer values into the same > database page, saving on I/O. If the I/O is from disk, this reduced > I/O cost, as small as it is likely to be, is still likely to save > significantly more than the integer decoding costs. I/O is just that > expensive next to processor cycles. That's my guess, anyways. I'm > not sure things would be so clear if you were working out of the > OS file system cache. > > Overall, you might be right... But if there is a difference, it > is likely related to the variable length nature of integers, not > something inherent in FP math being more expensive than integer math. > > -j > > -- > Jay A. Kreibich < J A Y @ K R E I B I.C H > > > "Intelligence is like underwear: it is important that you have it, > but showing it to the wrong people has the tendency to make them > feel uncomfortable." -- Angela Johnson > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- Gaurav Vyas Graduate Research Assistant, Transportation Engineering University of Texas at Austin _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
