Re: [Python-Dev] Speeding up CPython 5-10%

2016-01-29 Thread Damien George
Hi Yury, > An off-topic: have you ever tried hg.python.org/benchmarks > or compare MicroPython vs CPython? I'm curious if MicroPython > is faster -- in that case we'll try to copy some optimization > ideas. I've tried a small number of those benchmarks, but not in any rigorous way, and not

Re: [Python-Dev] FAT Python (lack of) performance

2016-01-29 Thread Peter Ludemann via Python-Dev
About benchmarks ... I've been there and it's not benchmarks that decide whether something succeeds or fails. (I found this old discussion which mentions FIB (also TAK , which is

Re: [Python-Dev] Speeding up CPython 5-10%

2016-01-29 Thread Stefan Behnel
Yury Selivanov schrieb am 27.01.2016 um 19:25: > tl;dr The summary is that I have a patch that improves CPython performance > up to 5-10% on macro benchmarks. Benchmarks results on Macbook Pro/Mac OS > X, desktop CPU/Linux, server CPU/Linux are available at [1]. There are no > slowdowns that I

Re: [Python-Dev] Speeding up CPython 5-10%

2016-01-29 Thread Yury Selivanov
On 2016-01-29 5:00 AM, Stefan Behnel wrote: Yury Selivanov schrieb am 27.01.2016 um 19:25: [..] LOAD_METHOD looks at the object on top of the stack, and checks if the name resolves to a method or to a regular attribute. If it's a method, then we push the unbound method object and the object

Re: [Python-Dev] Speeding up CPython 5-10%

2016-01-29 Thread Yury Selivanov
Hi Damien, BTW I just saw (and backed!) your new Kickstarter campaign to port MicroPython to ESP8266, good stuff! On 2016-01-29 7:38 AM, Damien George wrote: Hi Yury, [..] Do you use opcode dictionary caching only for LOAD_GLOBAL-like opcodes? Do you have an equivalent of LOAD_FAST, or you

Re: [Python-Dev] More optimisation ideas

2016-01-29 Thread francismb
Hi, > > Storing these in static data is a tradeoff between > disk space and startup performance, and one I think it likely to be > worthwhile. it's really an important trade off? As far a I understand from your email those modules are always being loaded and the final data created. won't the

Re: [Python-Dev] More optimisation ideas

2016-01-29 Thread Steve Dower
It doesn't currently end up on disk. Some tables are partially or completely stored on disk as Python source code (some are partially generated from simple rules), but others are generated by inverting those. That process takes time that could be avoided by storing the generated tables, and

Re: [Python-Dev] Speeding up CPython 5-10%

2016-01-29 Thread Steven D'Aprano
On Wed, Jan 27, 2016 at 01:25:27PM -0500, Yury Selivanov wrote: > Hi, > > > tl;dr The summary is that I have a patch that improves CPython > performance up to 5-10% on macro benchmarks. Benchmarks results on > Macbook Pro/Mac OS X, desktop CPU/Linux, server CPU/Linux are available > at [1].

[Python-Dev] More optimisation ideas

2016-01-29 Thread Steve Dower
Since we're all talking about making Python faster, I thought I'd drop some previous ideas I've had here in case (1) someone wants to actually do them, and (2) they really are new ideas that haven't failed in the past. Mostly I was thinking about startup time. Here are the list of modules

Re: [Python-Dev] How to resolve distinguishing between documentation and implementation

2016-01-29 Thread Guido van Rossum
Typically we fix this in the next feature release but not in bugfix releases, and that's what I recommend in this case. But deciding remains an art, not an exact science. People who catch specific lists of exceptions based on experience are bound to run into trouble occasionally, so I have little

[Python-Dev] Summary of Python tracker Issues

2016-01-29 Thread Python tracker
ACTIVITY SUMMARY (2016-01-22 - 2016-01-29) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open5381 (+27) closed 32615 (+30) total 37996 (+57) Open issues

[Python-Dev] How to resolve distinguishing between documentation and implementation

2016-01-29 Thread Serhiy Storchaka
How to resolve distinguishing between documentation and implementation if current implementation is incorrect, but third-party code can implicitly depends on it? For example see issue26198. Currently buffer overflow of predefined buffer for "es#" and "et#" format units causes TypeError (with

Re: [Python-Dev] How to resolve distinguishing between documentation and implementation

2016-01-29 Thread Brett Cannon
On Fri, 29 Jan 2016 at 10:14 Serhiy Storchaka wrote: > How to resolve distinguishing between documentation and implementation > if current implementation is incorrect, but third-party code can > implicitly depends on it? > > For example see issue26198. Currently buffer