X[~Z] faster than X[Z==0] :
In [13]: import numpy as np In [14]: X = np.random.random_integers(0, 1000, size=1000) In [15]: thresh = 50 In [18]: Z = X <= thresh In [19]: %timeit X_l, X_r = X[Z == 0], X[Z == 1] 10000 loops, best of 3: 23.9 us per loop In [20]: %timeit X_l, X_r = X[~Z], X[Z] 100000 loops, best of 3: 16.4 us per loop
Did you profile to determine that this is really a bottleneck in your code? If your code spends only 1% of its time performing this split operation, no matter how much you optimize this operation, there will be no more than 1% impact on overall performance.
You can make more use of rethinking your algorithm or data structure than optimizing this operation. And if this is really a bottleneck, you might also be better off rewriting this piece of code in C or Cython ...
When you have numpy arrays of size 1000, there is a possibility that using Python lists / sets / dicts might be faster. The speed advantage of NumPy arrays is sometimes not shown until the arrays are large enough. You might want to rewrite your code in pure Python and compare the two versions with timeit .
Hm, let me rephrase that. This is not the size of the array, which makes NumPy faster or slower. Its just that, with small NumPy arrays, it is sometimes a sign that you are creating many small NumPy arrays, and creating a NumPy array is much slower than creating, say, a Python list:
In [21]: %timeit np.array([]) 100000 loops, best of 3: 4.31 us per loop In [22]: %timeit [] 10000000 loops, best of 3: 29.5 ns per loop In [23]: 4310/295. Out[23]: 14.610169491525424
In addition, when coding in pure Python, you are most likely to use dicts and sets, for which there is no direct equivalent to NumPy. This can lead to an alternative algorithm, which is faster.