(original) (raw)
On 18 October 2015 at 17:41, Chris Angelico <rosuav@gmail.com> wrote:
On Mon, Oct 19, 2015 at 11:35 AM, David Mertz <mertz@gnosis.cx> wrote:
\> That's interesting about the \`self.\_full\` variable slowing it down, I think
\> I'm not surprised (but obviously it depends on just how it's used). But one
\> can also simply define RingBuffer.isfull() using \`self.max==len(self.data)\`
\> if you prefer that approach. I doubt \`myringbuffer.isfull()\` is something
\> you need to call in an inner loop.
\>
\> That said, I think my implementation of RingBuffer would probably look more
\> like (completely untested):
\>
\> class RingBuffer(object):
\> def \_\_init\_\_(self, size\_max):
\> self.data = \[None\] \* size\_max
\> self.size\_max = size\_max
\> self.used = 0
\> self.cur = 0
\> def append(self, val):
\> self.data\[self.cur\] = val
\> self.cur = (self.cur+1) % self.size\_max
\> self.used = max(self.used, self.cur+1)
\> def isfull(self):
\> self.used == self.size\_max
\>
\> Feel free to try this version against whatever benchmark you have in mind.
What does this provide that collections.deque(maxlen=size\_max)
doesn't? I'm a little lost.
I was merely re-implementing the "clever" code in a slightly less clever way, for the same performance, to demonstrate that there's no need to assign to \_\_class\_\_.
collections.deque is about 5x faster.
(My simple benchmark tests the cost of x.append(i))
- p
ChrisA
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/pludemann%40google.com