Nuno Lucas wrote: > On Wed, May 27, 2009 at 5:58 AM, Marcus Grimm <mgr...@medcom-online.de> wrote: >>> On Tue, May 26, 2009 at 9:47 PM, Marcus Grimm <mgr...@medcom-online.de> >>> http://www.sqlite.org/faq.html#q19 >> the faq as well as the speed comparison speaks about a few dozen >> of transaction per second... that's why I'm wondering why I'm >> almost ten times slower on windows... > > You don't say much about your hardware or how you are timing the > transaction speed, so 10 times slower for those numbers are within the > error margin.
my hardware is just a standard desktop computer, not the fastest... Okay, if my measurements are within the typical speed range, then this is the explanation why I see so much slower speed. > > Do the math yourself. It's more about disk rotation speed than any > other factor, as you have already seen when wrapping those INSERTs > within a transaction. Yes, I know... there has been also a funny proof some weeks ago here, that where refering to light-speed and the distance of the disc to the memory, as far as I can remeber. I'm very well aware of the speed limitations, it was just that I was puzzled by my results compared to the indication given on the sqlite pages. > > For comparison, use PRAGMA SYNCHRONOUS=OFF, which will return as soon > as the OS let's you (doesn't depend on the disk access). correct, I made some experiments today and switching the synchronous to off will give a dramatic speed improvement. Using the "normal" sync mode I achieve an appx. 20% improvement as well. Yes, I understood that this is unsafe and I'll not use it right now. But my feeling is that it will be an option for the future. My databases are not so big (say in megabyte range) and currently my server application will do a backup every day (more or less a simple file copy). So even if I'll see a corrupt database the customer will loose only one day work, as maximum. This should be tolerated since I estimate the liklyhood of such an event extremely low (powerfailure or OS crash at exactly the "wrong" time), powerfailure by the way can be workaround by using a battery pack which is common on server hardware, I guess. I agree that the new async vfs might help as well, havn't tried this yet. Thanks for sharing your thoughts kind regards Marcus > > But note that this option is not safe and I would discourage people > from using it until they understand very well what they are doing > (it's not easy, and many time impossible, to recover a corrupt SQLite > database). If you really want speed, you can try the new async VFS, > which will do the atomic writes in a background thread. > > > Regards, > ~Nuno Lucas > >> thanks for the reply >> >> Marcus > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
