21–30 of 50 posts
(1) By far the more common: giving a big-O analysis of some algorithm's running-time complexity.
(2) For performance-optimization roles: questions about using cache effectively, or take-home programming assignments in C++ or CUDA.
Theres all sorts of write ups on writing performant Python, it just comes depending on what you are working on, chances are high you are writing algos that have already been optimized and prewritten for you.
Some general tips for algorithmic complexity in Python:
- Python's list is equivalent to C++ std::vector. If you need to push/pop at the head of the list, use Python's "collections.deque" to avoid the O(N) cost. Python's standard library doesn't have a linked list implementation.
- Python's dict is a fast unordered hashmap. However, if you need order-aware operations like C++'s std::map::lower_bound(), you're out of luck; Python's standard library doesn't have a tree implementation.
- Python has a "bisect" module for binary searching in a Python list, and a "heapq" module for using a Python list as a heap. However, neither one is nicely encapsulated in a data type.
If your Python program is seriously CPU-bound, the normal solution is to use a C/C++/Rust extension. For example, if you're doing large numeric calculations, use NumPy; it can store a vector of numbers as a single contiguous array, which is much faster than a list-of-Python-floats.
If you want to parallelize across CPU cores, it's important to understand the Python GIL (global interpreter lock). Often you need to use multiple Python processes. See e.g. https://superfastpython.com/multiprocessing-pool-gil/
Maybe also worth reading about __slots__ (https://wiki.python.org/moin/UsingSlots); it's a micro-optimization that helps when allocating a lot of tiny Python objects.
Hope some of that is helpful! Good luck with your job interviews.
Every Pycon has at least one talk on it and they are usually filled with a variety of tips and insights.
Prioritise by keynote speeches, recent ones, country level ones and then city Pycon.
Many things that one might take as given in other languages, in Python are optional: static type analysis, multithreading, immutability and the like. When it comes to writing algorithms in Python, it's best to think about it as executable pseudocode, here to help you get to the correct execution first and optimise for performance later.
In Python, development happens in distinct steps. The first step is to get your code to do what you need, without thinking about the readability and efficiency. In many cases, this will result in the code that is ready to be used, even in production (especially if you include unit tests and type checking, for good measure); if not, the next step is to comb the code and optimise it to be faster. What that means exactly will depend on your needs, but with a combination of external libraries like NumPy, multiprocessing and async it is quite possible to reach sufficient performance.
Finally, if none of that result in the desired speed, the performance critical components can be extracted and rewritten in a low-level language (where you have a huge advantage as a C++ dev) that the Python will happily wrap around. This is the exact strategy used by most performant libraries out there, like NumPy itself.
I would say, there is no such thing as fast Python code. It's not the purpose of the language. You make want to take a look at Mojo: https://www.modular.com/max/mojo It's not really there yet, but the promise is to "combine the usability of Python with the performance of C"
> I would say, there is no such thing as fast Python code. It's not the purpose of the language. It's not the purpose of the language but (business) needs don't generally care about such things. Sometimes you can't rewrite in rust for a variety of reasons and then it can pay off to know what's faster rather than slower in CPython.
I would say, there is no such thing as fast Python code. It's not the purpose of the language. You make want to take a look at Mojo: https://www.modular.com/max/mojo It's not really there yet, but the promise is to "combine the usability of Python with the performance of C"
In many cases, it is possible to get Python code to within 2-10x of C using numpy/numba/cython... but with 10% of the lines of code. In many cases, this is an acceptable trade.
In Python job interviews, I think the interviewer will only judge your code on asymptotic complexity, not absolute speed. I think Python engineers generally aren't expected to know how to micro-optimize their Python code. Some general tips for algorithmic complexity in Python: - Python's list is equivalent to C++ std::vector. If you need to push/pop at the head of the list, use Python's "collections.deque" to avoid t…
I'm fairly certain that in Python 3.7 and later standard library dictionaries are now ordered by default.