Oh boy. My latest update to my commercial app contained a database update. As SQLite doesn't offer a general enough ALTER TABLE implementation, my program makes a copy of the affected table(s), and then recreates the table definitions, and finally copies the data from the old to the new, and drops the old.
This has been working great for years. But for some reason (perhaps people's databases have grown much larger than they were before) the update for one customer took 45 minutes, even though the total number of rows copied was < 10K. The customer thought the program was nonresponsive, even though I have a throbber, and force-quit during the update, corrupting the data. 2 other customers did the same thing. 3 other customers had no problem (not sure if their updates were relatively quick or not - I'm going to be calling them to find out). These are all XP or Vista machines. Seems some of them are taking a seriously long time to do the update, while my testing on my Vista/XP boxes happens reasonably quickly. I acquired the database of that one customer that took 45 minutes on his system, and ran it on my Vista, Mac, and Linux systems. The Vista system took 7 minutes, Mac 3 minutes, and Linux 2 minutes. I guess 10K rows in 7 minutes is in the realm of acceptable, but it still seems slow. But what could cause such slow performance on my customer's system. I watched the process with LogMeIn, and had task manager open. CPU usage was only at like 10% during the process, and memory usage for the app stayed at a constant 69-70 MB. I didn't watch disk I/O (how would I do that remotely in Windows?) Is there something in XP/Vista that would cause such severe slowdowns? The database lives (by default) in the user's %appdata% directory. I didn't notice any other process hogging resources. Any ideas, other than making it clear that they need to wait for the updating to occur? Paul _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/[email protected]
