There needs to be a set of benchmarks that can be used to test the effect of any changes. Is there a set that exist already that can be used? Barry > Behalf Of Vladimir Marangozov > > Continuing my impressions on the user's feedback to date: Donn Cave > & MAL are at least two voices I've heard about an overall slowdown > of the 2.0b1 release compared to 1.5.2. Frankly, I have no idea where > this slowdown comes from and I believe that we have only vague guesses > about the possible causes: unicode database, more opcodes in ceval, etc. > > I wonder whether we are in a position to try improving Python's > performance with some `wise quickies' in a next beta. But this raises > a more fundamental question on what is our margin for manoeuvres at this > point. This in turn implies that we need some classification of the > proposed optimizations to date. > > Perhaps it would be good to create a dedicated Web page for this, but > in the meantime, let's try to build a list/table of the ideas that have > been proposed so far. This would be useful anyway, and the list would be > filled as time goes. > > Trying to push this initiative one step further, here's a very rough start > on the top of my head: > > Category 1: Algorithmic Changes > > These are the most promising, since they don't relate to pure technicalities > but imply potential improvements with some evidence. > I'd put in this category: > > - the dynamic dictionary/string specialization by Fred Drake > (this is already in). Can this be applied in other areas? If so, where? > > - the Python-specific mallocs. Actually, I'm pretty sure that a lot of > `overhead' is due to the standard mallocs which happen to be expensive > for Python in both space and time. Python is very malloc-intensive. > The only reason I've postponed my obmalloc patch is that I still haven't > provided an interface which allows evaluating it's impact on the > mem size consumption. It gives noticeable speedup on all machines, so > it accounts as a good candidate w.r.t. performance. > > - ??? (maybe some parts of MAL's optimizations could go here) > > Category 2: Technical / Code optimizations > > This category includes all (more or less) controversial proposals, like > > - my latest lookdict optimizations (a typical controversial `quickie') > > - opcode folding & reordering. Actually, I'm unclear on why Guido > postponed the reordering idea; it has received positive feedback > and all theoretical reasoning and practical experiments showed that > this "could" help, although without any guarantees. Nobody reported > slowdowns, though. This is typically a change without real dangers. > > - kill the async / pending calls logic. (Tim, what happened with this > proposal?) > > - compact the unicodedata database, which is expected to reduce the > mem footprint, maybe improve startup time, etc. (ongoing) > > - proposal about optimizing the "file hits" on startup. > > - others? > > If there are potential `wise quickies', meybe it's good to refresh > them now and experiment a bit more before the final release? > > -- > Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr > http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://www.python.org/mailman/listinfo/python-dev >
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