Oren Tirosh wrote: > > On Mon, Feb 11, 2002 at 05:26:01PM -0500, Neal Norwitz wrote: > > I tried this patch (*) by running the regression tests: > > > > make && time ./python -E -tt Lib/test/regrtest.py > > > > All the expected tests passed and there were no failures, this is good. > > The bad news is that it was slower. It took 42 user seconds longer > > with the patch than without. > > I tried this and the results were identical for both version (+-1 second) > The regression tests most of their time on things like threads, sockets, > signals and stuff like that which is barely affected by this patch and > has a lot of other sources of variance. Some subset of the regression > tests may be good as a benchmark, though. > > I also got very strange results (some faster, some slower) with the > python2.2 RPM package and didn't start to get consistent results until I > used a freshly compiled interpreter for both the reference and DUT. I want > to see how the package was compiled and why it got such strange results. I was surprised by the results. I am using the latest version from CVS, plus I have some outstanding changes that would be unlikely to cause a conflict. They deal with removing consecutive line numbers (there is a patch on SF) and speeding up conditionals. Nothing that is remotely close to dictionaries. Here are all the options from the compile: gcc -c -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fkeep-inline-functions -fno-inline -fprofile-arcs -ftest-coverage -I. -I./Include -DHAVE_CONFIG_H It's possible that no inlining is hurting, but I would still have expected your patch to be faster than without. I also wouldn't expect the test coverage to be hurting (-fprofile-arcs -ftest-coverage), but that is possible. It would be nice if someone else could duplicate either of our results. Neal
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4