summaryrefslogtreecommitdiff
path: root/numpy/core/defchararray.py
diff options
context:
space:
mode:
authorRaul Cota <rcota@hotmail.com>2013-01-22 11:32:26 -0700
committerRaul Cota <rcota@hotmail.com>2013-01-22 11:32:26 -0700
commitcc70e5a0db562c96a4813f95990be72357591465 (patch)
tree4b6742e7f09b523af6d874ccc4a759081efaa822 /numpy/core/defchararray.py
parentce289ab57cd5249c41c6166c478b9d054fca4ddf (diff)
downloadnumpy-cc70e5a0db562c96a4813f95990be72357591465.tar.gz
Avoid conversion to NumPy Scalar
After profiling I noticed that a bottleneck for NumPy scalar operations occurs when trying to extract the underlying C value from a Python float because it first converts the Python scalar into its matching NumPy scalar (e.g. PyFloat -> float64) and then it extracts the C value from the NumPy scalar. For some types, it is a lot faster to just extract the value directly from the Python scalar. I only did for PyFloat in this modified code but the code is laid out such that it can be easily extended to other types such as Integers. I did not do them because I was unsure if there was a special scenario to handle across OS and/or between 32 and 64 bit platforms. The ratio of speed to do different operations are listed below (Old time / New time with modifications). In other words, the bigger the number, the bigger the speed up we get. Tested in Python 2.6 Windows RATIO TEST 1.1 Array * Array 1.1 PyFloat * Array 1.1 Float64 * Array 1.0 PyFloat + Array 1.3 Float64 + Array 1.1 PyFloat * PyFloat 1.0 Float64 * Float64 4.0 PyFloat * Float64 2.9 PyFloat * vector1[1] 3.9 PyFloat + Float64 9.8 PyFloat < Float64 9.9 PyFloat < Float64 1.0 Create array from list 1.0 Assign PyFloat to all 1.0 Assign Float64 to all 4.2 Float64 * pyFloat * pyFloat * pyFloat * pyFloat 1.0 pyFloat * pyFloat * pyFloat * pyFloat * pyFloat 1.0 Float64 * Float64 * Float64 * Float64 * Float64 1.0 Float64 ** 2 1.0 pyFloat ** 2
Diffstat (limited to 'numpy/core/defchararray.py')
0 files changed, 0 insertions, 0 deletions