On 29 January 2012 12:10, Stefan Behnel wrote:
> Stefan Behnel, 28.01.2012 21:14:
>> mark florisson, 28.01.2012 20:07:
>>> On 28 January 2012 18:38, Stefan Behnel wrote:
Stefan Behnel, 27.01.2012 09:02:
> any exception *propagation* is
> still substantially slower than necessary, and
Stefan Behnel, 28.01.2012 21:14:
> mark florisson, 28.01.2012 20:07:
>> On 28 January 2012 18:38, Stefan Behnel wrote:
>>> Stefan Behnel, 27.01.2012 09:02:
any exception *propagation* is
still substantially slower than necessary, and that's a general issue.
>>>
>>> Here's a general take o
Vitja Makarov, 28.01.2012 21:41:
> 2012/1/29 Stefan Behnel:
>> Vitja Makarov, 28.01.2012 20:58:
>>> 2012/1/28 mark florisson:
On 28 January 2012 19:41, Vitja Makarov wrote:
> 2012/1/28 Stefan Behnel:
>> Here's a general take on a code object cache for exception propagation.
>>
2012/1/29 Stefan Behnel :
> Vitja Makarov, 28.01.2012 20:58:
>> 2012/1/28 mark florisson :
>>> On 28 January 2012 19:41, Vitja Makarov wrote:
2012/1/28 Stefan Behnel :
> Stefan Behnel, 27.01.2012 09:02:
>> any exception *propagation* is
>> still substantially slower than necessary
On 28 January 2012 19:59, Vitja Makarov wrote:
> 2012/1/28 mark florisson :
>> On 28 January 2012 19:48, mark florisson wrote:
>>> On 28 January 2012 19:41, Vitja Makarov wrote:
2012/1/28 Stefan Behnel :
> Stefan Behnel, 27.01.2012 09:02:
>> any exception *propagation* is
>> sti
Vitja Makarov, 28.01.2012 20:58:
> 2012/1/28 mark florisson :
>> On 28 January 2012 19:41, Vitja Makarov wrote:
>>> 2012/1/28 Stefan Behnel :
Stefan Behnel, 27.01.2012 09:02:
> any exception *propagation* is
> still substantially slower than necessary, and that's a general issue.
mark florisson, 28.01.2012 20:07:
> On 28 January 2012 18:38, Stefan Behnel wrote:
>> Stefan Behnel, 27.01.2012 09:02:
>>> any exception *propagation* is
>>> still substantially slower than necessary, and that's a general issue.
>>
>> Here's a general take on a code object cache for exception propa
2012/1/28 mark florisson :
> On 28 January 2012 19:48, mark florisson wrote:
>> On 28 January 2012 19:41, Vitja Makarov wrote:
>>> 2012/1/28 Stefan Behnel :
Stefan Behnel, 27.01.2012 09:02:
> any exception *propagation* is
> still substantially slower than necessary, and that's a gen
2012/1/28 mark florisson :
> On 28 January 2012 19:41, Vitja Makarov wrote:
>> 2012/1/28 Stefan Behnel :
>>> Stefan Behnel, 27.01.2012 09:02:
any exception *propagation* is
still substantially slower than necessary, and that's a general issue.
>>>
>>> Here's a general take on a code obje
On 28 January 2012 19:48, mark florisson wrote:
> On 28 January 2012 19:41, Vitja Makarov wrote:
>> 2012/1/28 Stefan Behnel :
>>> Stefan Behnel, 27.01.2012 09:02:
any exception *propagation* is
still substantially slower than necessary, and that's a general issue.
>>>
>>> Here's a gener
On 28 January 2012 19:41, Vitja Makarov wrote:
> 2012/1/28 Stefan Behnel :
>> Stefan Behnel, 27.01.2012 09:02:
>>> any exception *propagation* is
>>> still substantially slower than necessary, and that's a general issue.
>>
>> Here's a general take on a code object cache for exception propagation.
2012/1/28 Stefan Behnel :
> Stefan Behnel, 27.01.2012 09:02:
>> any exception *propagation* is
>> still substantially slower than necessary, and that's a general issue.
>
> Here's a general take on a code object cache for exception propagation.
>
> https://github.com/scoder/cython/commit/ad18e0208
On 28 January 2012 18:38, Stefan Behnel wrote:
> Stefan Behnel, 27.01.2012 09:02:
>> any exception *propagation* is
>> still substantially slower than necessary, and that's a general issue.
>
> Here's a general take on a code object cache for exception propagation.
>
> https://github.com/scoder/cy
Stefan Behnel, 27.01.2012 09:02:
> any exception *propagation* is
> still substantially slower than necessary, and that's a general issue.
Here's a general take on a code object cache for exception propagation.
https://github.com/scoder/cython/commit/ad18e0208
When I raise an exception in test c
Vitja Makarov, 27.01.2012 20:17:
> https://github.com/cython/cython/commit/7ae9d5b9a66bb586cd0d03b3aa137eb762602087
Looks like it worked:
https://sage.math.washington.edu:8091/hudson/job/cython-devel-pybenchmarks-py3k/318/artifact/bench_chart.html#nqueens
https://sage.math.washington.edu:8091/hu
2012/1/27 Stefan Behnel :
> Vitja Makarov, 27.01.2012 12:02:
>> I'll push my patch to upstream.
>
> Please do.
>
https://github.com/cython/cython/commit/7ae9d5b9a66bb586cd0d03b3aa137eb762602087
>
>> One question: does it close the ticket or not?
>
> No.
>
>
>> Perhaps it's better to rename your t
Vitja Makarov, 27.01.2012 12:02:
> I'll push my patch to upstream.
Please do.
> One question: does it close the ticket or not?
No.
> Perhaps it's better to rename your ticket to something like
> "AddTraceback() is slow" as itsn't related to generators.
Ok, I'll do that and hang the time mach
2012/1/27 Stefan Behnel :
> Stefan Behnel, 26.01.2012 21:57:
>> Vitja Makarov, 26.01.2012 21:19:
>>> 2012/1/27 Stefan Behnel:
Robert Bradshaw, 21.01.2012 23:09:
> On Sat, Jan 21, 2012 at 10:50 AM, Stefan Behnel wrote:
>> I did some callgrind profiling on Cython's generators and was sur
Stefan Behnel, 26.01.2012 21:57:
> Vitja Makarov, 26.01.2012 21:19:
>> 2012/1/27 Stefan Behnel:
>>> Robert Bradshaw, 21.01.2012 23:09:
On Sat, Jan 21, 2012 at 10:50 AM, Stefan Behnel wrote:
> I did some callgrind profiling on Cython's generators and was surprised to
> find that AddTrac
Vitja Makarov, 26.01.2012 21:19:
> 2012/1/27 Stefan Behnel:
>> Robert Bradshaw, 21.01.2012 23:09:
>>> On Sat, Jan 21, 2012 at 10:50 AM, Stefan Behnel wrote:
I did some callgrind profiling on Cython's generators and was surprised to
find that AddTraceback() represents a serious performance
2012/1/27 Stefan Behnel :
> Robert Bradshaw, 21.01.2012 23:09:
>> On Sat, Jan 21, 2012 at 10:50 AM, Stefan Behnel wrote:
>>> I did some callgrind profiling on Cython's generators and was surprised to
>>> find that AddTraceback() represents a serious performance penalty for short
>>> running generat
Robert Bradshaw, 21.01.2012 23:09:
> On Sat, Jan 21, 2012 at 10:50 AM, Stefan Behnel wrote:
>> I did some callgrind profiling on Cython's generators and was surprised to
>> find that AddTraceback() represents a serious performance penalty for short
>> running generators.
>>
>> I profiled a compiled
On Sat, Jan 21, 2012 at 10:50 AM, Stefan Behnel wrote:
> Hi,
>
> I did some callgrind profiling on Cython's generators and was surprised to
> find that AddTraceback() represents a serious performance penalty for short
> running generators.
>
> I profiled a compiled Python implementation of itertoo
On 01/21/2012 07:50 PM, Stefan Behnel wrote:
Hi,
I did some callgrind profiling on Cython's generators and was surprised to
find that AddTraceback() represents a serious performance penalty for short
running generators.
I profiled a compiled Python implementation of itertools.groupby(), which
y
24 matches
Mail list logo
