Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #103620

Re: Bug in Python?

From "Sven R. Kunze" <srkunze@mail.de>
Newsgroups comp.lang.python
Subject Re: Bug in Python?
Date 2016-02-28 11:08 +0100
Message-ID <mailman.5.1456654139.9760.python-list@python.org> (permalink)
References <56D0CCE9.2000301@mail.de> <CACL+1asoZSWcuB2fX3qLNinu8Eo1aEeEd0o+c88=3dKbbJY-eA@mail.gmail.com>

Show all headers | View raw


On 27.02.2016 00:07, eryk sun wrote:
>   On Fri, Feb 26, 2016 at 4:08 PM, Sven R. Kunze <srkunze@mail.de> wrote:
>> Python sometimes seems not to hop back and forth between C and Python code.
>> Can somebody explain this?
> Normally a C extension would call PySequence_SetItem, which would call
> the type's sq_ass_item, which for MyList is slot_sq_ass_item. The
> latter function bridges the CPython and Python sides by binding and
> calling the overridden __setitem__ method.  However, the _heapq
> extension module uses `PyList_SET_ITEM(heap, 0, lastelt)`. This macro
> expands to `((PyListObject *)(heap))->ob_item[0] = lastelt`. This
> directly modifies the internal ob_item array of the list, so the
> overridden __setitem__ method is never called. I presume it was
> implemented like this with performance in mind, but I don't know
> whether or not that justifies the loss of generality.

I think this is true and it explains the huge performance penalty of the 
current RemovalHeap and XHeap implementation as it basically uses Python 
only (results here: http://bit.ly/1KU7CyW).

Shoot! I could have seen this earlier. I thought the performance penalty 
was due to calling __setitem__ and dict operations. But having all heap 
operations carried out in Python slows things down considerably of course.

Let's see if I can manage to create a more efficient mark-and-sweep 
approach which uses the C module.

Best,
Sven

Back to comp.lang.python | Previous | Next | Find similar | Unroll thread


Thread

Re: Bug in Python? "Sven R. Kunze" <srkunze@mail.de> - 2016-02-28 11:08 +0100

csiph-web