[Patches] [ python-Patches-876198 ] easiest 1% improvement in pystone ever

SourceForge.net noreply at sourceforge.net
Wed Feb 11 13:11:32 EST 2004


Patches item #876198, was opened at 2004-01-13 11:43
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876198&group_id=5470

Category: Core (C code)
Group: Python 2.4
Status: Open
>Resolution: Accepted
>Priority: 5
Submitted By: Michael Hudson (mwh)
>Assigned to: Michael Hudson (mwh)
Summary: easiest 1% improvement in pystone ever

Initial Comment:
I've always been a bit suspicious of the machinery to
allow arbitrary objects that support the read buffer
interface as the co_code attribute of code objects, but
didn't realise that hacking it out improved pystone by
a repeatable 1%!

Greg, according to CVS this is your feature I'm
proposing removing -- can you explain its value?

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2004-02-11 13:11

Message:
Logged In: YES 
user_id=6380

agreed

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-02-11 12:57

Message:
Logged In: YES 
user_id=80475

I think the patch should be accepted as originally proposed.
 Why have all the common environments pay for Flash ROM
support which is likely not being used anyway?

Precisely measuring the improvement isn't important.  On the
face of it, the patch does less work and is simpler --
that's good enough for me.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-02-11 11:30

Message:
Logged In: YES 
user_id=6656

> 1% is not something that can be measured reliably IMO (try
> it again with a different phase of the moon, or on a
> different box).

I have.  I was astonished that the difference was noticable,
so I tried it in quite a few places and styles.  But *shrug*.

I don't support making this a compile time option.  If you
want it, it's easy enough to put back in for yourself (and
if the flash ROM thing is your motivation, you'll be doing
your own build anyway...).

> How's that for a non-answer. :-)

It's certainly not an answer <wink>.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-02-06 23:54

Message:
Logged In: YES 
user_id=6380

1% is not something that can be measured reliably IMO (try
it again with a different phase of the moon, or on a
different box).

OTOH I don't think that anyone has ever actually made use of
this feature -- it was a request from Greg Stein but I doubt
he got to use it.

OT3H, compilation options like this tend to break the first
time someone updates the affected code -- nobody is going to
test with all possible combinations of weird compilation
options.

How's that for a non-answer. :-)

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-02-06 18:00

Message:
Logged In: YES 
user_id=80475

Consider making it a compilation option for small builds
(turned-off by default).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-02-06 15:18

Message:
Logged In: YES 
user_id=31435

IIRC, this was to allow small platforms to store code in ROM 
(or flash ROM) and run it directly from there, without needing 
to make a copy in limited RAM.  I don't know whether anyone 
has done that.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-02-06 13:57

Message:
Logged In: YES 
user_id=80475

Guido, I think this is reasonable, but it is an API change.
 Do you see any reason to support non-string co_code arguments?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876198&group_id=5470



More information about the Patches mailing list