Skip to main content
Bounty Ended with 50 reputation awarded by Aseem Bansal
Placed the code into your answer. It is easier to read the code here.
Source Link

Software timing benchmarks are notoriously noisy because your computer isn't a very good controlled experimental platform.

  • Some algorithms are nondeterministic. For instance, some quicksort implementations choose a random pivot element.
  • While you're running your benchmarks, your python process may get preempted by other running applications, operating system threads, etc.
  • Even if your process got the same amount of CPU during every run, the timing may be different because a different mix of applications is running so your processor's memory caches have different hit/miss patterns.
  • Some runs may get better branch prediction than others (again, due to the mix of other processes running). This will cause more pipeline stalls.

I would suspect that the effects I've given are given in order of decreasing strength (except that I believe Python's sort algorithm is deterministic, so the first effect is not a factor here). I also suspect that I've just scratched the surface.

EDIT:

OK, for reversing a number, suppose that your typical input will be 5 digits then you can use this.

if __name__ == "__main__":
    from timeit import Timer
    import random
    def test(f):
        f(random.randint(10000,99999))

    print Timer(lambda: test(reverse_num)).timeit(number = 10000000)
    print Timer(lambda: test(reverse_num2)).timeit(number = 10000000)

Software timing benchmarks are notoriously noisy because your computer isn't a very good controlled experimental platform.

  • Some algorithms are nondeterministic. For instance, some quicksort implementations choose a random pivot element.
  • While you're running your benchmarks, your python process may get preempted by other running applications, operating system threads, etc.
  • Even if your process got the same amount of CPU during every run, the timing may be different because a different mix of applications is running so your processor's memory caches have different hit/miss patterns.
  • Some runs may get better branch prediction than others (again, due to the mix of other processes running). This will cause more pipeline stalls.

I would suspect that the effects I've given are given in order of decreasing strength (except that I believe Python's sort algorithm is deterministic, so the first effect is not a factor here). I also suspect that I've just scratched the surface.

Software timing benchmarks are notoriously noisy because your computer isn't a very good controlled experimental platform.

  • Some algorithms are nondeterministic. For instance, some quicksort implementations choose a random pivot element.
  • While you're running your benchmarks, your python process may get preempted by other running applications, operating system threads, etc.
  • Even if your process got the same amount of CPU during every run, the timing may be different because a different mix of applications is running so your processor's memory caches have different hit/miss patterns.
  • Some runs may get better branch prediction than others (again, due to the mix of other processes running). This will cause more pipeline stalls.

I would suspect that the effects I've given are given in order of decreasing strength (except that I believe Python's sort algorithm is deterministic, so the first effect is not a factor here). I also suspect that I've just scratched the surface.

EDIT:

OK, for reversing a number, suppose that your typical input will be 5 digits then you can use this.

if __name__ == "__main__":
    from timeit import Timer
    import random
    def test(f):
        f(random.randint(10000,99999))

    print Timer(lambda: test(reverse_num)).timeit(number = 10000000)
    print Timer(lambda: test(reverse_num2)).timeit(number = 10000000)
Source Link
ruds
  • 3.3k
  • 16
  • 23

Software timing benchmarks are notoriously noisy because your computer isn't a very good controlled experimental platform.

  • Some algorithms are nondeterministic. For instance, some quicksort implementations choose a random pivot element.
  • While you're running your benchmarks, your python process may get preempted by other running applications, operating system threads, etc.
  • Even if your process got the same amount of CPU during every run, the timing may be different because a different mix of applications is running so your processor's memory caches have different hit/miss patterns.
  • Some runs may get better branch prediction than others (again, due to the mix of other processes running). This will cause more pipeline stalls.

I would suspect that the effects I've given are given in order of decreasing strength (except that I believe Python's sort algorithm is deterministic, so the first effect is not a factor here). I also suspect that I've just scratched the surface.