-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21/03/12 16:57, Udi Karni wrote: > Frankly I don't know if a 64-bit version and Big RAM would make a > difference and if so - up to what point.
A 64 bit Windows command shell won't wave a magic wand. In any event you can compile one yourself and do your own measurements on your own data. However you are wasting your time. > With SQLite being a single process - assigned for the most part to a > single CPU - even if everything was done in RAM - there is a limit to > what 1 CPU can do. The operating system can use other CPUs doing I/O scheduling, read ahead etc. > I am just noticing anecdotally that SQlite uses cache and dealing with > tables of a few hundred MB or less doesn't seem to generate IO. The default cache size in SQLite is 2MB. If you are getting no I/O then it means your working set fits in that much space. > Also - when there is IO - it often comes from the swap file (under > Windows 7). You'll need to analyze what is happening. For example it could be other programs being paged out due to memory pressure. > So the questions are - They all depend on your workload. There is no magic bullet you are missing that will suddenly make things ten times faster. > (1) how much RAM is the point of diminishing returns on 32-bit Depends on what you are doing. In my comment specifically it was about the SQLite cache. When something is not in SQLite's cache it will ask the operating system which is almost instantaneous (if in the cache). Consequently you can consider the two complementary. Making SQLite's larger reduces the amount available for the operating system. You aren't going to see an appreciable difference in data coming from SQLite's cache versus the operating system cache. There will of course be a huge difference when data is fetched from an I/O device. > (2) is there value to going 64-bit Unless you are running out of address space, no. (In theory there are more registers and CPU bound activity could be faster, but SQLite isn't doing that much anyway.) You also incur a penalty of memory pointers doubling in size. Note that you can still run the 32 bit SQLite process on a 64 bit operating system with oodles of RAM. The OS can use all of that RAM for caching. However caches are only useful when you have working sets - ie data that is accessed more than once. > (3) if there was a 64-bit version - would it use more RAM more > effectively? Nope. You just get to be able to have more address space in a process. > (4) as a fallback - let's say the 32-bit version and 4GB are as good as > you can pretty much expect. Would getting a server with 4 CPUs and 16GB > (a high-end home-version PC) - reasonably enable me to run 3-4 SQLite > jobs concurrently? In other words - no great speed improvement per job > - but in aggregate more work could get done? Depends what you are limited by. If the I/O systems for each database are completely independent (ie separate buses) and memory bandwidth is not saturated then you'll get an appropriate speedup/concurrency. However again you seem to be seeking out some magic bullet. There isn't one. You'll only get good answers by running your own workloads. Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk9qfiwACgkQmOOfHg372QQNYACgqCwN6+ME23LNZcntUMI3hMXM G3gAoKvc2+a4N66M6p0vqYxCbDM72VmF =xVxc -----END PGP SIGNATURE----- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
