On Sat, Mar 24, 2012 at 06:56:16PM -0700, Roger Binns scratched on the wall: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 24/03/12 18:23, Jay A. Kreibich wrote: > > That depends on the OS. Some 64-bit OSes will give nearly all the 4GB > > address space to a 32-bit application. > > Those same OSes make it very easy to compile SQLite in 64 bits so this > isn't an issue.
Not to nit-pick, but an OS doesn't make it, or not make it, difficult to compile something. That's usually due to crappy tools and poor support. Then again, the last time I compiled SQLite on Windows, I was using a non-Visual Studio, command line compiler. > > Others, like Windows, will only give half the space, and reserve the > > other half of the address space for system mappings. > > See also /3GB Under Windows, yes, but not all OSes that split application address space allow the boundary to be moved. Perhaps, "Others, like Windows defaults," would have been more specific. Your point that most of these OSes also have solid tool support is well taken, however. > > True, but in-memory databases do not require I/O. Additionally, I/O > > caching is done by the OS. Even with a 32-bit SQLite process, if the > > system has more than 2GB of RAM, a 64-bit OS is going to be able to use > > any additional RAM (including that beyond 4GB) for I/O caching. > > The scenario was using a ramdisk. Yeah, I missed that "in memory database" wasn't a ":memory:" database. > If the system has 16GB of memory and 15GB of memory is used for a > ramdisk then only 1GB is available for I/O caching. True, but the OS doesn't typically cache filesystems on a ramdisk. Caching slows things down and wastes memory. > The point is to be careful using memory for single purposes (files on a > ramdisk) since it can't be used for other things at the same time. Under > normal circumstances the OS can use memory for whatever is most needed at > a point in time be it caching or for process heap and code. True enough... although there is some assumption you know how to measure and analyze resource allocations when you start to do stuff like allocate ramdisks and such. Or not. I suppose everyone knows someone like an old (and thankfully "ex") colleague of mine that got all excited about the possibility of moving his swap files to a RAM disk... "Sure it will swap a bit more, but it will be *SOOO* fast!!" -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
