On 10 July 2012 09:05, Andrew Dalke wrote:
> On Jul 8, 2012, at 9:22 AM, Scott Sinclair wrote:
>> On 6 July 2012 15:48, Andrew Dalke wrote:
>>> I followed the instructions at
>>> http://docs.scipy.org/doc/numpy/dev/gitwash/patching.html
>>> and added Ticket #2181 (with patch) ...
>>
>> Those ins
Andrew,
Thank you for your comments. I agree it's confusing coming to github at
first. I still have to refer to the jargon-file to understand what everything
means. There are a lot of unfamiliar terms.
Thank you for your patches. It does imply more work for developers on NumPy,
whic
On Jul 8, 2012, at 9:22 AM, Scott Sinclair wrote:
> On 6 July 2012 15:48, Andrew Dalke wrote:
>> I followed the instructions at
>> http://docs.scipy.org/doc/numpy/dev/gitwash/patching.html
>> and added Ticket #2181 (with patch) ...
>
> Those instructions need to be updated to reflect the current
On 6 July 2012 15:48, Andrew Dalke wrote:
> I followed the instructions at
> http://docs.scipy.org/doc/numpy/dev/gitwash/patching.html
> and added Ticket #2181 (with patch) at
> http://projects.scipy.org/numpy/ticket/2181
Those instructions need to be updated to reflect the current preferred
pr
I followed the instructions at
http://docs.scipy.org/doc/numpy/dev/gitwash/patching.html
and added Ticket #2181 (with patch) at
http://projects.scipy.org/numpy/ticket/2181
This remove the 5 'exec' calls from polynomial/*.py and improves
the 'import numpy' time by about 25-30%. That is, on my lap
On Tue, Jul 3, 2012 at 1:16 AM, Andrew Dalke wrote:
> On Jul 3, 2012, at 12:46 AM, David Cournapeau wrote:
> > It is indeed irrelevant to your end goal, but it does affect the
> > interpretation of what import_array does, and thus of your benchmark
>
> Indeed.
>
> > Focusing on polynomial seems th
On Mon, Jul 2, 2012 at 2:59 PM, Nathaniel Smith wrote:
> On Mon, Jul 2, 2012 at 10:06 PM, Robert Kern wrote:
>> On Mon, Jul 2, 2012 at 9:43 PM, Benjamin Root wrote:
>>>
>>> On Mon, Jul 2, 2012 at 4:34 PM, Nathaniel Smith wrote:
>>
I think this ship has sailed, but it'd be worth looking int
On Mon, Jul 2, 2012 at 12:17 PM, Andrew Dalke wrote:
> In this email I propose a few changes which I think are minor
> and which don't really affect the external NumPy API but which
> I think could improve the "import numpy" performance by at
> least 40%.
+1 -- I think I remember that thread -- a
On Jul 3, 2012, at 12:46 AM, David Cournapeau wrote:
> It is indeed irrelevant to your end goal, but it does affect the
> interpretation of what import_array does, and thus of your benchmark
Indeed.
> Focusing on polynomial seems the only sensible action. Except for
> test, all the other stuff se
On Jul 3, 2012, at 12:21 AM, Nathaniel Smith wrote:
> Yes, but for a proper benchmark we need to compare this to the number
> that we would get with some other implementation... I'm assuming you
> aren't proposing we just delete the docstrings :-).
I suspect that we have a different meaning of the
On Mon, Jul 2, 2012 at 11:15 PM, Andrew Dalke wrote:
> On Jul 2, 2012, at 11:38 PM, Fernando Perez wrote:
>> No, that's the wrong thing to test, because it effectively amounts to
>> 'import numpy', sicne the numpy __init__ file is still executed. As
>> David indicated, you must import multarray.s
On Mon, Jul 2, 2012 at 11:15 PM, Andrew Dalke wrote:
> On Jul 2, 2012, at 11:38 PM, Fernando Perez wrote:
>> No, that's the wrong thing to test, because it effectively amounts to
>> 'import numpy', sicne the numpy __init__ file is still executed. As
>> David indicated, you must import multarray.s
On Mon, Jul 2, 2012 at 3:15 PM, Andrew Dalke wrote:
>
> Thus, I don't see any way that I can import 'multiarray' directly,
> because the underlying C code is the one which imports
> 'numpy.core.multiarray' and by design it is inaccessible to change
> from Python code.
I was just referring to how
On Mon, Jul 2, 2012 at 10:44 PM, Andrew Dalke wrote:
> On Jul 2, 2012, at 10:34 PM, Nathaniel Smith wrote:
>> I don't have any opinion on how acceptable this would be, but I also
>> don't see a benchmark showing how much this would help?
>
> The profile output was lower in that email. The relevant
On Jul 2, 2012, at 11:38 PM, Fernando Perez wrote:
> No, that's the wrong thing to test, because it effectively amounts to
> 'import numpy', sicne the numpy __init__ file is still executed. As
> David indicated, you must import multarray.so by itself.
I understand that clarification. However, it
On Mon, Jul 2, 2012 at 10:06 PM, Robert Kern wrote:
> On Mon, Jul 2, 2012 at 9:43 PM, Benjamin Root wrote:
>>
>> On Mon, Jul 2, 2012 at 4:34 PM, Nathaniel Smith wrote:
>
>>> I think this ship has sailed, but it'd be worth looking into lazy
>>> importing, where 'numpy.fft' isn't actually imported
On Jul 2, 2012, at 10:34 PM, Nathaniel Smith wrote:
> I don't have any opinion on how acceptable this would be, but I also
> don't see a benchmark showing how much this would help?
The profile output was lower in that email. The relevant line is
0.038 add_newdocs (numpy.core.multiarray)
This say
On Mon, Jul 2, 2012 at 2:26 PM, Andrew Dalke wrote:
>
> so the relevant timing test is more likely:
>
> % time python -c 'import numpy.core.multiarray'
> 0.086u 0.031s 0:00.12 91.6% 0+0k 0+0io 0pf+0w
No, that's the wrong thing to test, because it effectively amounts to
'import numpy', sicne t
On Jul 2, 2012, at 10:33 PM, David Cournapeau wrote:
> On Mon, Jul 2, 2012 at 8:17 PM, Andrew Dalke
> wrote:
>> In July of 2008 I started a thread about how "import numpy"
>> was noticeably slow for one of my customers.
...
>> I managed to get the import time down from 0.21 seconds to
>> 0.08
02.07.2012 21:17, Andrew Dalke kirjoitti:
[clip]
> 1) remove "add_newdocs" and put the docstrings in the C code
> 'add_newdocs' still needs to be there,
The docstrings need to be in an easily parseable format, because of the
online documentation editor. Keeping the current format may be the
easie
On Mon, Jul 2, 2012 at 9:43 PM, Benjamin Root wrote:
>
> On Mon, Jul 2, 2012 at 4:34 PM, Nathaniel Smith wrote:
>> I think this ship has sailed, but it'd be worth looking into lazy
>> importing, where 'numpy.fft' isn't actually imported until someone
>> starts using it. There are a bunch of libr
On Mon, Jul 2, 2012 at 4:34 PM, Nathaniel Smith wrote:
> On Mon, Jul 2, 2012 at 8:17 PM, Andrew Dalke
> wrote:
> > In this email I propose a few changes which I think are minor
> > and which don't really affect the external NumPy API but which
> > I think could improve the "import numpy" perform
On Mon, Jul 2, 2012 at 8:17 PM, Andrew Dalke wrote:
> In this email I propose a few changes which I think are minor
> and which don't really affect the external NumPy API but which
> I think could improve the "import numpy" performance by at
> least 40%. This affects me because I and my clients us
On Mon, Jul 2, 2012 at 8:17 PM, Andrew Dalke wrote:
> In this email I propose a few changes which I think are minor
> and which don't really affect the external NumPy API but which
> I think could improve the "import numpy" performance by at
> least 40%. This affects me because I and my clients us
In this email I propose a few changes which I think are minor
and which don't really affect the external NumPy API but which
I think could improve the "import numpy" performance by at
least 40%. This affects me because I and my clients use a
chemistry toolkit which uses only NumPy arrays, and where
25 matches
Mail list logo
