Duncan Booth wrote:
John Posner <jjpos...@snet.net> wrote:
Do know what in the itertools implementation causes adding a 'if p <=
sqrt(n)' clause to *decrease* performance, while adding a
'takewhile()' clause *increases* performance?

I haven't timed it, but I would guess that the takewhile was faster only because the sqrt(n) had been factored out of the loop. Try the original loop again precalculating the sqrt(n) and see how that compares.
Here's my "timeit" scorecard, with repeat=5 (only the minimum value reported) and number=5000:

**** all prev. primes
3.97347791658

**** prev. primes that don't exceed SQRT
6.23250413579

**** [CACHED] prev. primes that don't exceed SQRT
3.45557325672

**** [TAKEWHILE] prev. primes that don't exceed SQRT
0.371197373201

**** [TAKEWHILE] squares, using *, of prev. primes that don't exceed N
0.358001074011

**** [TAKEWHILE] squares, using **, of prev. primes that don't exceed N
0.383540147515

**** [TAKEWHILE, CACHED] squares, using *, of prev. primes that don't exceed N
0.410309506343

**** [TAKEWHILE, CACHED] squares, using **, of prev. primes that don't exceed N
0.401269222462


So ... adding the SQRT optimization degrades the performance significantly, but adding CACHING to the SQRT optimization swings the performance pendulum back to the "benefit" side. TAKEWHILE is a big win, but adding CACHING to TAKEWHILE degrades performance.

The code (110 lines) is at http://cl1p.net/python_prime_generators/

-John

--
http://mail.python.org/mailman/listinfo/python-list

Reply via email to