Interesting timing issue I noticed
*Gabriel Genellina* gagsl-py2 at yahoo.com.ar python-list%40python.org?Subject=Interesting%20timing%20issue%20I%20noticedIn-Reply-To= *Wed Apr 16 08:44:10 CEST 2008* Another thing would be to rearrange the loops so the outer one executes less times; if you know that borderXsizeX and borderYsizeY it may be better to swap the inner and outer loops above. Thank you for the tip on xrange. Even if I swap the inner and outer loops, I would still be doing the same number of computations, am I right (since I still need to go through the same number of elements)? I'm not seeing how a loop swap would lead to fewer computations, since I still need to calculate the outer rim of elements in the array (defined by borderX and borderY). ~ Jon -- Perhaps we all give the best of our hearts uncritically, to those who hardly think about us in return. ~ T.H.White -- http://mail.python.org/mailman/listinfo/python-list
Re: Interesting timing issue I noticed
I've written up a stripped down version of the code. I apologize for the bad coding; I am in a bit of a hurry. import random import sys import time sizeX = 320 sizeY = 240 borderX = 20 borderY = 20 # generates a zero matrix def generate_zero(): matrix = [[0 for y in range(sizeY)] for x in range(sizeX)] return matrix # fills zero matrix def fill_matrix(in_mat): mat = in_mat for x in range(sizeX): for y in range(sizeY): mat[x][y] = random.randint(1, 100) return mat ## # COMPUTES ONLY A PART OF THE ARRAY def back_diff_one(back_array, fore_array, box): diff_array = generate_zero() start = time.time() for x in range(sizeX): for y in range(borderY): diff_array[x][y] = back_array[x][y] - fore_array[x][y] for y in range((sizeY - borderY), sizeY): diff_array[x][y] = back_array[x][y] - fore_array[x][y] for y in range(borderY, (sizeY - borderY)): for x in range(borderX): diff_array[x][y] = back_array[x][y] - fore_array[x][y] for x in range((sizeX - borderX), sizeX): diff_array[x][y] = back_array[x][y] - fore_array[x][y] # tracks object if (len(box) != 0): for x in range(box[0], box[2]): for y in range(box[1], box[3]): diff_array[x][y] = back_array[x][y] - fore_array[x][y] print time one inside = + str(time.time() - start) return diff_array ## # COMPUTES EVERY ELEMENT IN THE ARRAY def back_diff_two(back_array, fore_array): diff_array = generate_zero() start = time.time() for y in range(sizeY): for x in range(sizeX): diff_array[x][y] = back_array[x][y] - fore_array[x][y] end = time.time() print time two inside = + str(end - start) return diff_array ## # CODE TO TEST BOTH FUNCTIONS back = fill_matrix(generate_zero()) fore = fill_matrix(generate_zero()) box = [20, 20, 268, 240] start1 = time.time() diff1 = back_diff_one(back, fore, box) print time one outside = + str(time.time() - start1) start2 = time.time() diff2 = back_diff_two(back, fore) print time one outside = + str(time.time() - start2) Here are some results from several test runs: time one inside = 0.078686646 time one outside = 0.125 time two inside = 0.078686646 time two outside = 0.14132425 RESTART time one inside = 0.062637604 time one outside = 0.125 time two inside = 0.078961853 time two outside = 0.125 RESTART time one inside = 0.062362396 time one outside = 0.13866486 time two inside = 0.078686646 time two outside = 0.125 RESTART time one inside = 0.078686646 time one outside = 0.172000169754 time two inside = 0.078961853 time two outside = 0.125 RESTART time one inside = 0.078686646 time one outside = 0.125 time two inside = 0.078686646 time two outside = 0.125 RESTART time one inside = 0.062362396 time one outside = 0.155999898911 time two inside = 0.078686646 time two outside = 0.125 RESTART time one inside = 0.077999830246 time one outside = 0.125 time two inside = 0.077999830246 time two outside = 0.125 RESTART time one inside = 0.078686646 time one outside = 0.17103815 time two inside = 0.077999830246 time two outside = 0.125 RESTART time one inside = 0.062637604 time one outside = 0.1876376 time two inside = 0.062362396 time two outside = 0.125 Why is a large percentage of the time, the execution time for the (ostensibly smaller) first loop is actually equal to or LARGER than the second? -- Perhaps we all give the best of our hearts uncritically, to those who hardly think about us in return. ~ T.H.White -- http://mail.python.org/mailman/listinfo/python-list
Interesting timing issue I noticed
The project I'm working on is motion detection, involving a bit of image processing. No worries: no image processing background needed. Suffice to say that I initially wrote a script that goes through every pixel of a 320x240 picture (turned into an array using PIL) and performs some calculatiosn. It simply goes through every pixel in the array and performs a simple subtraction with a known value. The idea is to try to find differences between the two images. After a while, to try to speed up the calculations, I realized that I didn't need to do all 320x240 calculations. So I implemented a slightly more sophisticated algorithm and localized my calculations. I still do the pixel subtractions, but I do it on a smaller scale. Surprisingly, when I used time.time() to time the procedures, I find that doing all 320x240 calculations are often faster! On my machine, the former gives me on average an execution time of around 0.125s (and consistently), whereas the latter on average takes 0.160s. Why does this happen? -- Perhaps we all give the best of our hearts uncritically, to those who hardly think about us in return. ~ T.H.White -- http://mail.python.org/mailman/listinfo/python-list
Question on threads
Hi all, I'm a beginner to Python, so please bear with me. Is there a way of guarenteeing that all created threads in a program are finished before the main program exits? I know that using join() can guarentee this, but from the test scripts I've run, it seems like join() also forces each individual thread to terminate first before the next thread can finish. So if I create like 20 threads in a for loop, and I join() each created thread, then join() will in effect cause the threads to be executed in serial rather than in parallel. ~ Jon -- Perhaps we all give the best of our hearts uncritically, to those who hardly think about us in return. ~ T.H.White -- http://mail.python.org/mailman/listinfo/python-list
Re: Question on threads
On Fri, Apr 11, 2008 at 3:29 PM, Steve Holden [EMAIL PROTECTED] wrote: Jonathan Shao wrote: Hi all, I'm a beginner to Python, so please bear with me. Is there a way of guarenteeing that all created threads in a program are finished before the main program exits? I know that using join() can guarentee this, but from the test scripts I've run, it seems like join() also forces each individual thread to terminate first before the next thread can finish. So if I create like 20 threads in a for loop, and I join() each created thread, then join() will in effect cause the threads to be executed in serial rather than in parallel. No it won't, as in fact there is no mechanism to force a thread to terminate in Python. When you join() each created thread the main thread will wait for each thread to finish. Supposing the longest-lived thread finished first then all others will immediately return from join(). The only requirement it is imposing is that all sub-threads must be finished before the main thread terminates. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ I guess I'm doing something wrong with join(). Here's a test script I wrote up... import threading import time class TestThread(threading.Thread): def __init__(self, region): self.region = region threading.Thread.__init__(self) def run(self): for loop in range(10): print Region + str(self.region) + reporting: + str(loop) time.sleep(2) for x in range(10): thr = TestThread(x) thr.start() thr.join() raw_input() In this script thread 0 will finish first... Am I doing something wrong with join()? -- http://mail.python.org/mailman/listinfo/python-list
