Raymond Hettinger added the comment:
0.0699 usec per loop -- 0.0468
That's pretty good for a small patch :-)
For the pre-computed 1-tuple, I think you need to check for a refcnt of 1 and
fallback to PyTuple_New if the tuple is in use (i.e. a property that calls
another property). See
Raymond Hettinger added the comment:
Hmm, the presense of _PyTuple_DebugMallocStats, repeat_traverse, and
visit_decref suggests that the profile may have been run with debugging code
enabled and GC enabled.
The property patch looks good. Depending on how far you want to go with this,
you
Joe Jevnik added the comment:
I switched to the static tuple.
--
Added file: http://bugs.python.org/file39216/with-static-tuple.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23910
___
Joe Jevnik added the comment:
I don't think that I can cache the __call__ of the fget object because it might
be an instance of a heaptype, and if someone changed the __class__ of the
object in between calls to another heaptype that had a different __call__, you
would still get the __call__
Raymond Hettinger added the comment:
What kind of speed improvement have you gotten?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23910
___
Joe Jevnik added the comment:
I am currently on a different machine so these numbers are not relative to the
others posted earlier.
* default
./python -m timeit -s from collections import namedtuple as n;a = n('n', 'a b
c')(1, 2, 3) a.a
1000 loops, best of 3: 0.0699 usec per loop
* patch
Raymond Hettinger added the comment:
One other thought: the itemgetter.__call__ method is already pretty thin:
if (!PyArg_UnpackTuple(args, itemgetter, 1, 1, obj))
return NULL;
if (nitems == 1)
return PyObject_GetItem(obj, ig-item);
But you could add a special case for
Joe Jevnik added the comment:
I was unable to see a performance increase by playing with the
itemgetter.__call__ code; however, updating the propery code seemed to show a
small improvement. I think that for simple indexing the cost of checking if it
is a sequence outways the faster dispatch
Raymond Hettinger added the comment:
FWIW, the current property(itemgetter(index)) code has a Python creation step,
but the actual attribute lookup and dispatch is done entirely in C (no pure
python steps around the eval lookup).
Rather than making a user visible C hack directly to
Raymond Hettinger added the comment:
If you have a chance, run a C profiler so we can see whether most of the time
is being spent in an attribute lookup for the current property(itemgetter)
approach versus your nt-indexer approach. Without a profile, I have only my
instincts that the
Joe Jevnik added the comment:
This was very exciting, I have never run gprof before; so just to make sure I
did this correctly, I will list my steps:
1. compile with the -pg flag set
1. run the test with ./python -m timeit ...
1. $ gprof python gmon.out profile.out
Here is default:
Each
Joe Jevnik added the comment:
I am updating the patch to include an entry in Misc/NEWS.
--
Added file: http://bugs.python.org/file38994/namedtuple-indexer-with-news.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23910
Joe Jevnik added the comment:
sorry, I meant pypy
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23910
___
___
Python-bugs-list mailing list
Joe Jevnik added the comment:
# Original version / new python implementation
./python -m timeit -s from collections import namedtuple;a = namedtuple('a',
'a b c')(1, 2, 3) a.a
1000 loops, best of 3: 0.07 usec per loop
# C implementation
./python -m timeit -s from collections import
Joe Jevnik added the comment:
I stripped down the patch to only the descriptor like we had discussed.
--
Added file: http://bugs.python.org/file38896/namedtuple.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23910
Changes by Raymond Hettinger raymond.hettin...@gmail.com:
--
assignee: - rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23910
___
___
Raymond Hettinger added the comment:
Can you post before and afters timings of the patch?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23910
___
Changes by Serhiy Storchaka storch...@gmail.com:
--
nosy: +rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23910
___
___
Python-bugs-list
New submission from Joe Jevnik:
I am working on implementing nameduple in C; I am almost there; however, on the
path of moving to full compatibility, I ran into a refcount issue somewhere.
Hopefully someone can help me work this out.
To describe the issue, When I run the collections tests I
Eric V. Smith added the comment:
What's the motivating use case for this?
--
nosy: +eric.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23910
___
Joe Jevnik added the comment:
Ideally, namedtuple is used to make your code cleaner, using magic indecies
is less clear than using a named index in a lot of cases. Because namedtuple is
mainly to make the code more readable, I don't think that it should have an
impact on the runtime
Eric V. Smith added the comment:
Have you thought of just exposing Object/structseq.c?
Before you put much time into this, I'd get Raymond's acceptance of whatever
approach you want to take. It might be best to raise it on python-ideas.
--
___
Changes by Barry A. Warsaw ba...@python.org:
--
nosy: +barry
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23910
___
___
Python-bugs-list mailing
Joe Jevnik added the comment:
would the idea be to deprecate namedtuple in favor of a public structseq that
is exposed through collections, or change structseq to fit the namedtuple API?
--
___
Python tracker rep...@bugs.python.org
Eric V. Smith added the comment:
I haven't seen thought it through, just that it seems very similar to a C
namedtuple.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23910
___
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23910
___
___
Python-bugs-list
26 matches
Mail list logo
