On Sun, Oct 11, 2009 at 7:40 PM, Tim Chase <django.us...@tim.thechases.com>wrote:
> > > On my oldest slowest machine (7 year old WinXP box with 384M of memory), > > Then you're not far off -- my home work-horse is an 8-year-old > Celeron laptop clocked at 800MHz with 384M of memory running > Debian off a fairly slow HDD. My 800MHz Celeron laptop got retired about a year ago when it quit wanting to stay powered on for more than 5 minutes. I thought I'd kept it long past its expire date but you've clearly got me beat. > After "an hour and change" (fairly > close to your 1.5hr benchmark) at lunch, I aborted on the > assumption that there had to be a better way. Especially for > tight iterations on changes against trunk (working on a patch > against core/trunk from a ticket I created). I've svn-up'ed to > the latest to ensure I've got everything as current as possible, > but I'm fairly sure that was already the case. I manually > specified ":memory:" and sqlite, letting it run to completion > this time and it took just over an hour: > > Ran 867 tests in 3775.195s > > I'll try Russel's suggestion to minimize the time spent running > so I can do some quick(er) iterations before re-running the full > suite. > > Note my 1.5 hours was for the 1.0.X branch, not trunk. That's why I was thinking you must be using a DB that didn't support rollback, but if you are using sqlite then that is not what's causing things to be so slow. (You also should not have to specify memory as the DB for testing sqlite, it should do that automatically though I haven't verified that is working...so far as I know it is working.) For me, tests for trunk using sqlite ran in 15 minutes. My machine is faster than yours, 1.3GHz vs. 800MHz. But that doesn't seem likely to account for your case taking four times longer to run. Two other ideas -- what else are you running on this when you run the tests? The 15 minutes in my case was with basically nothing else running (with just 384M memory it's easy to overload this poor box). I tried a 2nd run after starting a couple of browsers so that the memory was overcommitted, and the testing wall clock time went up to 24 minutes. Second, what version of Python? The 15 minute result for me was with Python 2.6. Backing off to Python 2.5 (plus keeping the memory overcommitted) made the wall clock time go up to 30 minutes. I also recall from running tests against Python 2.3 to check for 2.3 compatibility that those ran what seemed to be much slower than later levels (though I don't have Python 2.3 on this particular machine to put a number on "much"). My general impression from running tests against 2.3, 2.4, 2.5, 2.6 when doing compatibility testing was that later Pythons were faster, though I never took specific measurements to quantify that impression. So, making sure your machine is not swapping, if possible, and updating to a recent Python if you are currently running an older one, might help. Finally as to the 50 missing tests noted in another thread -- some tests are skipped if you don't have various optional bits (e.g. PIL, markdown, etc.) installed. I've got probably nothing optional installed on this machine I've mentioned here and it is reporting 862 tests run. Karen --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
