Re: [sage-devel] Re: yet another sage-python performance puzzle

2017-09-18 Thread Nils Bruin
On Monday, September 18, 2017 at 3:08:11 AM UTC-7, Jeroen Demeyer wrote: > > On 2017-09-16 03:31, Nils Bruin wrote: > > So if you're finding you can't put a "from A import a" at the top-level > > and using it locally has noticeable cost (which can easily happen: > > imports have a significant

Re: [sage-devel] Re: yet another sage-python performance puzzle

2017-09-18 Thread Jeroen Demeyer
On 2017-09-15 21:48, Travis Scrimshaw wrote: On Friday, September 15, 2017 at 2:31:05 PM UTC-5, Maarten Derickx wrote: Is it assymptotically 10% or is it 10% for the case in which you are testing it? In the first case I would be surprised in the second case it is not that weird.

Re: [sage-devel] Re: yet another sage-python performance puzzle

2017-09-18 Thread Jeroen Demeyer
On 2017-09-16 03:31, Nils Bruin wrote: So if you're finding you can't put a "from A import a" at the top-level and using it locally has noticeable cost (which can easily happen: imports have a significant cost, even for modules that are already present), then you could try to do a straight

[sage-devel] Re: yet another sage-python performance puzzle

2017-09-16 Thread Simon King
Hi! On 2017-09-16, Nils Bruin wrote: > On Friday, September 15, 2017 at 2:28:06 PM UTC-7, Travis Scrimshaw wrote: >>> Why are you proposing local imports? If python puts a performance penalty >>> on them (in fact a significant performance penalty), they should be >>> avoided,

[sage-devel] Re: yet another sage-python performance puzzle

2017-09-15 Thread Nils Bruin
On Friday, September 15, 2017 at 2:28:06 PM UTC-7, Travis Scrimshaw wrote: > > > Why are you proposing local imports? If python puts a performance penalty >> on them (in fact a significant performance penalty), they should be >> avoided, no? >> >> It is a relatively small penalty, so when it is

[sage-devel] Re: yet another sage-python performance puzzle

2017-09-15 Thread 'Martin R' via sage-devel
Am Freitag, 15. September 2017 23:28:06 UTC+2 schrieb Travis Scrimshaw: > > > Why are you proposing local imports? If python puts a performance penalty >> on them (in fact a significant performance penalty), they should be >> avoided, no? >> >> It is a relatively small penalty, so when it is

[sage-devel] Re: yet another sage-python performance puzzle

2017-09-15 Thread Travis Scrimshaw
> Why are you proposing local imports? If python puts a performance penalty > on them (in fact a significant performance penalty), they should be > avoided, no? > > It is a relatively small penalty, so when it is not in a tight loop, it is useful to break out of those cyclic imports (and has

[sage-devel] Re: yet another sage-python performance puzzle

2017-09-15 Thread 'Martin R' via sage-devel
I agree. Then I have to remove the local import. Am Freitag, 15. September 2017 21:50:01 UTC+2 schrieb Travis Scrimshaw: > > > > On Friday, September 15, 2017 at 2:39:29 PM UTC-5, Martin R wrote: >> >> I haven't done any "professional" profiling, but it seems to me that the >> 10% are stable,

[sage-devel] Re: yet another sage-python performance puzzle

2017-09-15 Thread 'Martin R' via sage-devel
Why are you proposing local imports? If python puts a performance penalty on them (in fact a significant performance penalty), they should be avoided, no? It's not that I'm doing these optimizations just for fun. I am applying many of these little maps very very very often. I am now

[sage-devel] Re: yet another sage-python performance puzzle

2017-09-15 Thread Travis Scrimshaw
On Friday, September 15, 2017 at 2:39:29 PM UTC-5, Martin R wrote: > > I haven't done any "professional" profiling, but it seems to me that the > 10% are stable, i.e., roughly independent of the size of the permutation. > > I just found a much faster alternative: simply bypass

[sage-devel] Re: yet another sage-python performance puzzle

2017-09-15 Thread Travis Scrimshaw
On Friday, September 15, 2017 at 2:31:05 PM UTC-5, Maarten Derickx wrote: > > Is it assymptotically 10% or is it 10% for the case in which you are > testing it? In the first case I would be surprised in the second case it is > not that weird. > > See the late_import function in

[sage-devel] Re: yet another sage-python performance puzzle

2017-09-15 Thread 'Martin R' via sage-devel
I haven't done any "professional" profiling, but it seems to me that the 10% are stable, i.e., roughly independent of the size of the permutation. I just found a much faster alternative: simply bypass MatrixSpace.matrix completely: entries = { (v-1, i): 1 for i, v in enumerate(self) }

[sage-devel] Re: yet another sage-python performance puzzle

2017-09-15 Thread Maarten Derickx
Is it assymptotically 10% or is it 10% for the case in which you are testing it? In the first case I would be surprised in the second case it is not that weird. See the late_import function in src/sage/rings/complex_field.py for how you can speed up the import statement for the cyclic import