I don't know about SQL Lite or MySQL, but at work we recently released a product that uses SQL Server. I thought, databases are slow and so I should probably have some sort of file cache locally to save the user from having to hit the DB over and over again. In certain situations DBs will be slow. Clients may have a shoddy or busy network where hitting the DB over the network will be a pain. In my particular case, good GB network or local DB, cache saving and loading was about as fast as hitting the DB. Mind you I was keeping the cache simple, dumping to XML. All that ASCII translation and the libxml2 library added a lot of over head. Changed the code to dump to a binary (no translation to ASCII) and managed to speed up the file load and save by half. Then along comes the gumby who wrote the DB code and mentioned he was doing some silly things and improved the speed a bit. I don't know how much faster my binary dump is anymore with the latest. It's humbling. The guys who code SQL server do a lot to eek out any performance they can. They 'cache' a lot in memory. If you are talking to a server somewhere else on the net then your local computer will do some caching so that only the first fetch is slow but subsequent ones may not be. Other big database offerings will do similar tricks. Even though the database is on the hard drive, or possibly over a network, it's quite possible that a lot of the data is copied into memory on your machine. You can't beat that if your alternative solution is to find and read a file. Robbert de Groot --- On Sat, 5/22/10, Ethan Grammatikidis <eekee57@xxxxxxxxxxx> wrote: > On 22 May 2010, at 06:56, Chris Nystrom wrote: > > > > SQLite seems to be far more trouble to use than simply > creating > > arrays. I assume that as you scale up though, it is > important for > > performance to have an actual database instead of > internal arrays of > > data. Is there a rule of thumb about when you should > use a database? > > Or is there some other reason to use SQL besides > performance with > > large systems? > > I've just begin a very long project to gather data on just > this sort of question, just when where and how is the right > way to use each available technology. An inevitable side > effect will be finding out if some technologies are worth > anything at all. > > As to SQL itself I haven't anything definite yet, just an > impression that for a straightforward key:value mapping it > may not be worth using at all. Filesystems provide key:value > as name:file, and am I right in thinking that file access is > generally faster than database access? Last I heard (about a > year ago) MySQL was much higher performance than SQLite, and > I don't think MySQL can't match speed with a filesystem > lookup. (How can it, when it uses the filesystem as a > backend anyway?) --------------------- To unsubscribe go to http://gameprogrammer.com/mailinglist.html