Mailman 3 February 2001 - Python-Dev

Re: [Python-Dev] Showstopper in import?
by Michael Hudson Feb. 2, 2001

Feb. 2, 2001

Thomas Wouters <thomas(a)xs4all.net> writes: > On Fri, Feb 02, 2001 at 01:15:14PM +0000, Michael Hudson wrote: > > [ Compiler exceptions (as opposed to runtime exceptions) sucks ] > > > The fix? Presumably rigging compile.c:com_error to set up tracebacks > > properly? It looks like it *tries* to, but I don't know this area of > > the code well enough to understand why it doesn't work. Anyone? > > Have you seen this ? > > http://sourceforge.… [View More]

1 0

Re: [Python-Dev] Showstopper in import?
by Michael Hudson Feb. 2, 2001

Feb. 2, 2001

"Tim Peters" <tim.one(a)home.com> writes: > > Percolator has "from x import *" code. This is what is causing the > > exception. > > Woo hoo! The traceback bamboozled me: it doesn't show any code from > Percolator.py, just the import in EditorWindow.py. So I'll call *that* the > bug <0.7 wink>. > > > I think it has already been fixed in CVS though, so should > > work again. > > Doesn't work for me. If someone does patch Percolator.… [View More]

2 1

Re: [Python-Dev] Adding pymalloc to the core (Benchmarking "fun" (was Re: Python 2.1 slower than 2.0))
by Michael Hudson Feb. 2, 2001

Feb. 2, 2001

Thomas Wouters <thomas(a)xs4all.net> writes: > On Fri, Feb 02, 2001 at 12:24:32PM +0000, Michael Hudson wrote: > > > > Anyone else for adding [pyobjmalloc] now on an opt-in basis ? > > > Yes. I also want to try adding it in and then scrapping the free list > > management done by ints, frames, etc. and seeing if it this results in > > any significant slowdown. Don't have time for another mega-benchmark > > just now though. > > We could (… [View More]

1 0

Re: [Python-Dev] Adding pymalloc to the core (Benchmarking "fun" (was Re: Python 2.1 slower than 2.0))
by Michael Hudson Feb. 2, 2001

Feb. 2, 2001

"M.-A. Lemburg" <mal(a)lemburg.com> writes: > Thomas Wouters wrote: > > > > On Fri, Feb 02, 2001 at 11:00:28AM +0100, M.-A. Lemburg wrote: > > > > > There would be a need for a PEP if we need to discuss APIs, > > > interfaces, etc. but all this has already been done by Valdimir > > > a long time ago. He put much effort into getting the Python > > > malloc macros to work in the intended way so that pymalloc only > > > has … [View More]

2 1

any opinion on 'make quicktest'?
by Jeremy Hylton Feb. 1, 2001

Feb. 1, 2001

I run the regression test a lot. I have found that it is often useful to exclude some of the slowest tests for most of the test runs and then do a full test run before I commit changes. Would anyone be opposed to a quicktest target in the Makefile that supports this practice? There are a small number of tests that each take at least 10 seconds to complete. Jeremy Index: Makefile.pre.in =================================================================== RCS file: /cvsroot/python/python/… [View More]

4 5

python setup.py fails with illegal import (+ fix)
by Sjoerd Mullender Feb. 1, 2001

Feb. 1, 2001

With the current CVS version, running python setup.py as part of the build process fails with a syntax error: Traceback (most recent call last): File "../setup.py", line 12, in ? from distutils.core import Extension, setup File "/usr/people/sjoerd/src/python/Lib/distutils/core.py", line 20, in ? from distutils.cmd import Command File "/usr/people/sjoerd/src/python/Lib/distutils/cmd.py", line 15, in ? from distutils import util, dir_util, file_util, archive_util, dep_util … [View More]

2 1

insertdict slower?
by Jeremy Hylton Feb. 1, 2001

Feb. 1, 2001

I was curious about what the DictCreation microbenchmark in pybench was slower (about 15%) with 2.1 than with 2.0. I ran both with profiling enabled (-pg, no -O) and see that insertdict is a fair bit slower in 2.1. Anyone with dict implementation expertise want to hazard a guess about this? The profiler indicates the insertdict() is about 30% slower in 2.1, when the keys are all ints. int_hash() isn't any slower, but dict_ass_sub() is about 50% slower. Of course, this is a microbenchmark … [View More]that focuses on one tiny corner of dictionary usage: creating dictionaries with integer keys. This may not be a very useful measure of dictionary performance. Jeremy Results for Python 2.0 Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls ms/call ms/call name 54.55 3.90 3.90 285 13.68 19.25 eval_code2 6.71 4.38 0.48 4500875 0.00 0.00 lookdict 5.17 4.75 0.37 3000299 0.00 0.00 dict_dealloc 5.03 5.11 0.36 4506429 0.00 0.00 PyDict_SetItem 3.78 5.38 0.27 4500170 0.00 0.00 PyObject_SetItem 2.94 5.59 0.21 1500670 0.00 0.00 dictresize 2.80 5.79 0.20 4513037 0.00 0.00 insertdict 2.52 5.97 0.18 3000333 0.00 0.00 PyDict_New 2.38 6.14 0.17 4510126 0.00 0.00 PyObject_Hash 2.38 6.31 0.17 4500459 0.00 0.00 int_hash 2.24 6.47 0.16 3006844 0.00 0.00 gc_list_append 2.10 6.62 0.15 4500115 0.00 0.00 dict_ass_sub 1.68 6.74 0.12 3006759 0.00 0.00 gc_list_remove 1.68 6.86 0.12 3001745 0.00 0.00 PyObject_Init 1.26 6.95 0.09 3005413 0.00 0.00 _PyGC_Insert Results for Python 2.1 Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls ms/call ms/call name 50.00 3.83 3.83 998 3.84 3.84 eval_code2 6.40 4.32 0.49 4520965 0.00 0.00 lookdict 4.70 4.68 0.36 4519083 0.00 0.00 PyDict_SetItem 4.70 5.04 0.36 3001756 0.00 0.00 dict_dealloc 4.18 5.36 0.32 4500441 0.00 0.00 PyObject_SetItem 3.39 5.62 0.26 4531084 0.00 0.00 insertdict 3.00 5.85 0.23 4500354 0.00 0.00 dict_ass_sub 2.48 6.04 0.19 4507608 0.00 0.00 int_hash 2.35 6.22 0.18 4576793 0.00 0.00 PyObject_Hash 2.22 6.39 0.17 3003590 0.00 0.00 PyObject_Init 2.22 6.56 0.17 3002045 0.00 0.00 PyDict_New 2.22 6.73 0.17 1502861 0.00 0.00 dictresize 1.96 6.88 0.15 3023157 0.00 0.00 gc_list_remove 1.70 7.01 0.13 3020996 0.00 0.00 _PyGC_Remove 1.57 7.13 0.12 3023452 0.00 0.00 gc_list_append [View Less]

1 0

Benchmarking "fun" (was Re: Python 2.1 slower than 2.0)
by Michael Hudson Feb. 1, 2001

Feb. 1, 2001

In the interest of generating some numbers (and filling up my hard drive), last night I wrote a script to build lots & lots of versions of python (many of which turned out to be redundant - eg. -O6 didn't seem to do anything different to -O3 and pybench doesn't work with 1.5.2), and then run pybench with them. Summarised results below; first a key: src-n: this morning's CVS (with Jeremy's f_localsplus optimisation) (only built this with -O3) src: CVS from yesterday afternoon src-… [View More]obmalloc: CVS from yesterday afternoon with Vladimir's obmalloc patch applied. More on this later... Python-2.0: you can guess what this is. All runs are compared against Python-2.0-O2: Benchmark: src-n-O3 (rounds=10, warp=20) Average round time: 49029.00 ms -0.86% Benchmark: src (rounds=10, warp=20) Average round time: 67141.00 ms +35.76% Benchmark: src-O (rounds=10, warp=20) Average round time: 50167.00 ms +1.44% Benchmark: src-O2 (rounds=10, warp=20) Average round time: 49641.00 ms +0.37% Benchmark: src-O3 (rounds=10, warp=20) Average round time: 49104.00 ms -0.71% Benchmark: src-O6 (rounds=10, warp=20) Average round time: 49131.00 ms -0.66% Benchmark: src-obmalloc (rounds=10, warp=20) Average round time: 63276.00 ms +27.94% Benchmark: src-obmalloc-O (rounds=10, warp=20) Average round time: 46927.00 ms -5.11% Benchmark: src-obmalloc-O2 (rounds=10, warp=20) Average round time: 46146.00 ms -6.69% Benchmark: src-obmalloc-O3 (rounds=10, warp=20) Average round time: 46456.00 ms -6.07% Benchmark: src-obmalloc-O6 (rounds=10, warp=20) Average round time: 46450.00 ms -6.08% Benchmark: Python-2.0 (rounds=10, warp=20) Average round time: 68933.00 ms +39.38% Benchmark: Python-2.0-O (rounds=10, warp=20) Average round time: 49542.00 ms +0.17% Benchmark: Python-2.0-O3 (rounds=10, warp=20) Average round time: 48262.00 ms -2.41% Benchmark: Python-2.0-O6 (rounds=10, warp=20) Average round time: 48273.00 ms -2.39% My conclusion? Python 2.1 is slower than Python 2.0, but not by enough to care about. Interestingly, adding obmalloc speeds things up. Let's take a closer look: $ python pybench.py -c src-obmalloc-O3 -s src-O3 PYBENCH 0.7 Benchmark: src-O3 (rounds=10, warp=20) Tests: per run per oper. diff * ------------------------------------------------------------------------ BuiltinFunctionCalls: 843.35 ms 6.61 us +2.93% BuiltinMethodLookup: 878.70 ms 1.67 us +0.56% ConcatStrings: 1068.80 ms 7.13 us -1.22% ConcatUnicode: 1373.70 ms 9.16 us -1.24% CreateInstances: 1433.55 ms 34.13 us +9.06% CreateStringsWithConcat: 1031.75 ms 5.16 us +10.95% CreateUnicodeWithConcat: 1277.85 ms 6.39 us +3.14% DictCreation: 1275.80 ms 8.51 us +44.22% ForLoops: 1415.90 ms 141.59 us -0.64% IfThenElse: 1152.70 ms 1.71 us -0.15% ListSlicing: 397.40 ms 113.54 us -0.53% NestedForLoops: 789.75 ms 2.26 us -0.37% NormalClassAttribute: 935.15 ms 1.56 us -0.41% NormalInstanceAttribute: 961.15 ms 1.60 us -0.60% PythonFunctionCalls: 1079.65 ms 6.54 us -1.00% PythonMethodCalls: 908.05 ms 12.11 us -0.88% Recursion: 838.50 ms 67.08 us -0.00% SecondImport: 741.20 ms 29.65 us +25.57% SecondPackageImport: 744.25 ms 29.77 us +18.66% SecondSubmoduleImport: 947.05 ms 37.88 us +25.60% SimpleComplexArithmetic: 1129.40 ms 5.13 us +114.92% SimpleDictManipulation: 1048.55 ms 3.50 us -0.00% SimpleFloatArithmetic: 746.05 ms 1.36 us -2.75% SimpleIntFloatArithmetic: 823.35 ms 1.25 us -0.37% SimpleIntegerArithmetic: 823.40 ms 1.25 us -0.37% SimpleListManipulation: 1004.70 ms 3.72 us +0.01% SimpleLongArithmetic: 865.30 ms 5.24 us +100.65% SmallLists: 1657.65 ms 6.50 us +6.63% SmallTuples: 1143.95 ms 4.77 us +2.90% SpecialClassAttribute: 949.00 ms 1.58 us -0.22% SpecialInstanceAttribute: 1353.05 ms 2.26 us -0.73% StringMappings: 1161.00 ms 9.21 us +7.30% StringPredicates: 1069.65 ms 3.82 us -5.30% StringSlicing: 846.30 ms 4.84 us +8.61% TryExcept: 1590.40 ms 1.06 us -0.49% TryRaiseExcept: 1104.65 ms 73.64 us +24.46% TupleSlicing: 681.10 ms 6.49 us -3.13% UnicodeMappings: 1021.70 ms 56.76 us +0.79% UnicodePredicates: 1308.45 ms 5.82 us -4.79% UnicodeProperties: 1148.45 ms 5.74 us +13.67% UnicodeSlicing: 984.15 ms 5.62 us -0.51% ------------------------------------------------------------------------ Average round time: 49104.00 ms +5.70% *) measured against: src-obmalloc-O3 (rounds=10, warp=20) Words fail me slightly, but maybe some tuning of the memory allocation of longs & complex numbers would be in order? Time for lectures - I don't think algebraic geometry is going to make my head hurt as much as trying to explain benchmarks... Cheers, M. -- ARTHUR: But which is probably incapable of drinking the coffee. -- The Hitch-Hikers Guide to the Galaxy, Episode 6 [View Less]

4 5

Re: Sets: elt in dict, lst.include - really begs for a PEP
by Ka-Ping Yee Feb. 1, 2001

Feb. 1, 2001

On Tue, 30 Jan 2001, Guido van Rossum wrote: > > Can you say "PEP time"? :-) Okay, i have written a draft PEP that tries to combine the "elt in dict", custom iterator, and "for k:v" issues into a coherent proposal. Have a look: http://www.lfw.org/python/pep-iterators.txt http://www.lfw.org/python/pep-iterators.html Could i get a number for this please? -- ?!ng "The only `intuitive' interface is the nipple. After that, it's all learned." -- Bruce Ediger, on user interfaces

7 11

Re: [Python-checkins] CVS: python/dist/src/Misc NEWS,1.108,1.109
by Thomas Wouters Feb. 1, 2001

Feb. 1, 2001

On Mon, Jan 29, 2001 at 05:27:30PM -0800, Jeremy Hylton wrote: > add note about two kinds of illegal imports that are now checked > + - The compiler will report a SyntaxError if "from ... import *" occurs > + in a function or class scope or if a name bound by the import > + statement is declared global in the same scope. The language > + reference has also documented that these cases are illegal, but > + they were not enforced. Woah. Is this really a good idea ? I … [View More]

4 9