4 ms·
You've picked a poor example, I think. And you're probably coding in an inefficient way. Here's the OpenCV way for a pair of 2048x2048 images: import cv2
by joshvm 11y ago
You've picked a poor example, I think. And you're probably coding in an inefficient way.
Here's the OpenCV way for a pair of 2048x2048 images:
import cv2
import time
t = time.clock()
a = cv2.imread("./image_1.tiff", cv2.IMREAD_GRAYSCALE);
b = cv2.imread("./image_0.tiff", cv2.IMREAD_GRAYSCALE);
c = a-b
cv2.imwrite("out.tiff", c);
print time.clock()-t
Takes about 0.2 CPU seconds on average for me (note using time.clock, not time.time on UNIX).
#include <opencv2/opencv.hpp>
#include <ctime>
using namespace cv;
using namespace std;
int main(void){
clock_t begin = clock();
Mat a = imread("./image_1.tiff", IMREAD_GRAYSCALE);
Mat b = imread("./image_0.tiff", IMREAD_GRAYSCALE);
Mat c = a - b;
imwrite("out.tiff", c);
clock_t end = clock();
double elapsed_secs = double(end - begin) / CLOCKS_PER_SEC;
cout << elapsed_secs << endl;
}
Again, about 0.2 seconds. The difference is negligible if you use the right libraries. Python should not be your bottleneck for high performance code.
- coryrc 11y agoMy conclusion is: as long as you don't do anything new, Python is fast enough.
- ProblemFactory 11y agoThat's true, but most of the time you can express the "new" stuff in terms of existing fast libraries. I've had a few cases where you can't, and have become a big fan of Cython for that. It lets you add C typedefs to Python code, and then compile the module at import time. Example here: http://pastebin.com/sF8KmyiU http://pastebin.com/sF8KmyiU All of pure Python is still allowed in these modules, but the typedeffed variables become pure C variables instead of objects, and loops become pure C loops. For this particular function, I got a 1000x speedup compared to the original Python code. In the end, this isn't Python any more - but it's close enough, and only needed for loops that run over millions of items.
- Someone 11y agoNow, try implement that matrix subtraction or something more complex such as blurring or edge detection in Python, and compare results. Also, are you sure that doesn't measure disk speed?
- tanlermin 11y agoOk. But I would do it in Numba.
- joshvm 11y agoI get around 0.07 seconds without the write in C++ and the same in Python (good call though). I agree that in pure Python it'd be slower, but realistically why would you do that? Unless you work somewhere where you're forced to write your own libraries... but even then you could still implement your own.
- Someone 11y agoIf you only removed the write and not the reads from the timing, I would guess the reads (even with warm caches) still dominate the time. And you would want to do it in pure Python if you want to answer the question "how fast can we make interpreted Python?". Using C extensions for that is cheating, as it isn't Python and it isn't interpreted. You don't answer the question "how fast can you run?" With "30 km an hour, using a bicycle", either. If you make those images large enough (and I guess 2k x 2k is large enough), any language that uses OpenCV to do the job will give results in the same ballpark. For example, you can make the difference between Python implementations that can call OpenCV as small as you want it.
- RussianCow 11y agoNot the parent, but I think the point is that, in the real world, the vast majority of use cases for which Python is slow are ones where you would use an existing library written in a lower-level language. So questions like "How fast can we make matrix multiplication in Python?" are irrelevant for the vast majority of Python developers because NumPy exists, and it's always going to be faster than anything you can write in pure Python.
- joelg236 11y agoBe aware that python opencv uses c++ calls, it's only a wrapper. SciPy or numpy might be better examples.
- ihnorton 11y ago> SciPy or numpy might be better examples. Python comprises less than 50% of the code in both of those repositories, but they are certainly great for learning the CPython API.
- joshvm 11y agoI was under the impression that Numpy also just calls BLAS underneath? Hence why doing element-wise calls in Numpy is far, far faster than simply doing nested for loops. But I think this is the great strength of Python. It's a glue language. If you need speed, you can always write a wrapper around a C/C++ library.
- dietrichepp 11y agoFunny you should say C/C++, because BLAS is Fortran.
- howeman 11y agoActually, it's mostly assembly (depending on the particular implementation). Lapack is Fortran though.
- true_religion 11y ago> The difference is negligible if you use the right libraries. OpenCV is written in C++, it's going to be fairly efficient to call out to it in any language. For me, most of the time spent in our code is in 'business logic' which necessarily must be in the main language of the codebase. That's where PyPy gets its wins.