Michael Hudson wrote:
>
> > Since not using PySequence_Fast() to initialize the protocol,
> > I'd suggest doing a Py_FatalError() with some explanatory
> > text which gets printed to stderr -- still better than a
> > segfault at some later point due to some dangling pointers...
>
> So you'd want PySequence_Fast_GETITEM to look like
>
> #define PySequence_Fast_GETITEM(s,i) \
> (PyList_Check((s)) ? PyList_GET_ITEM((s),(i)) : \
> (PyTuple_Check((s))? PyTuple_GET_ITEM((s),(i)) : \
> Py_FatalError("muffin!") ))
>
> ? That'd probably be fair - you'd want to check any performance hit, but
> I wouldn't be surprised if it was neglible.
Yes.
> [Fredrik's PySequence_Fast_* APIs]
> >
> > I think Fredrik speculated on having the compiler optimizers
> > taking care of the check...
>
> gcc 2.95.1 doesn't seem to - even with -O9 you get stuff like
>
> .stabn 68,0,825,.LM312-string_join
> .LM312:
> movl PyList_Type@GOT(%ebx),%eax
> cmpl %eax,4(%edi)
> jne .L875
> movl 12(%edi),%eax
> jmp .L898
> .p2align 4,,7
> .L875:
> leal 12(%edi),%eax
> .L898:
> movl -32(%ebp),%edx
> movl (%eax,%edx,4),%esi
>
> ... but I'm no expert in assembly reading.
>
> > hmm, it would probably also help
> > to somehow declare PyTypeObject slots "const" -- is this possible
> > in a struct definition ?
>
> I have no idea!
Me neither -- it could help the compiler when moving type
checks out of inner loops: the type slot of PyObject normally
doesn't change (except on Windows where you have to patch it
in order make VC++ happy).
Anyone got a working idea in this direction ?
--
Marc-Andre Lemburg
______________________________________________________________________
Company: http://www.egenix.com/
Consulting: http://www.lemburg.com/
Python Pages: http://www.lemburg.com/python/
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