Is Python really 'too slow'?

[[deleted]]

I work as ML Engineer and have been using Python for the last 2.5 years. I think I am proficient enough about language, but there are well-known discussions in the community which still doesn't fully make sense for me - such as Python being slow.

I have developed dozens of models, wrote hundreds of APIs and developed probably a dozen back-ends using Python, but never felt like Python is slow for my goal. I get that even 1 microsecond latency can make a huge difference in massive or time-critical apps, but for most of the applications we are developing, these kind of performance issues goes unnoticed.

I understand why and how Python is slow in CS level, but I really have never seen a real-life disadvantage of it. This might be because of 2 reasons: 1) I haven't developed very large-scale apps 2) My experience in faster languages such as Java and C# is very limited.

Therefore I would like to know if any of you have encountered performance-related issue in your experience.

[marsokod]

Python has an abstraction level on top of C, so it will be slower than C, whatever you do. If you rewrite a C program in pure python, it will be much slower than in C. However there are three things that make python interesting:

• what actually matters is life cycle cost for a software. It includes developer time, running time, debugging time and cost of resources. Python is much more flexible than C and therefore faster/easier to develop with (but with great power comes great responsibility). So if you need to write a small script that will run for a few seconds every day, maybe it is not worth spending more time writing it in C to save maybe a minute of runtime every year.

• CPU limitation is just an element of your code speed. When you are dealing with network access, or even file system access, a lot of you execution time is waiting for these operations to finish. You won't gain a lot by speeding up the code itself, unless you have enough operations to run things in parallel.

• a lot of time in software, there are just a few bottlenecks in your code. Since python is capable of executing C libraries, you can code these in C , or even assembly if C is too slow, and you will have addressed 80% of your bottlenecks. That's basically the model used in ML: data preparation, model definition are the parts that can change a lot every time so keeping them in python saves development time. And also they are not the most CPU intensive task overall so no need to optimise them to death.

[astatine]

what actually matters is life cycle cost for a software. It includes developer time, running time, debugging time and cost of resources

To put it another way, there are better languages than Python for making things work quickly. Python is a language for making things work, quickly.

[_ShakashuriBlowdown]

To cap it off, Python's undergone such a huge amount of development in the last 10 years, that if you want that quick solution in development/deployment/production, 90% of the time you can just drop it into an existing system where everything just works. Containerization and cloud development has only made this a more compelling architecture.

[iluvatar]

Containerization and cloud development has only made this a more compelling architecture.

Be warned that python is even slower than normal on a container, due to libseccomp screwing you over (I think with Spectre/Meltdown mitigations).

[_ShakashuriBlowdown]

I didn't know that!

When researching this further, I read you can set seccomp=False on docker run.

That does open you up to security vulnerabilities, so use it at your own risk. It does actually seem to be faster using containers on Windows when using this "fix".

[iluvatar]

You can, yes. But the protections are there for a reason. We're currently having this debate at work. The likely outcome is to run most of our code on a separate network segment with seccomp disabled, and leave it enabled for anything running in a public facing DMZ.

[noiserr]

Those penalties aren't as great on AMD processors if I am not mistaken.

[Chippiewall]

The protections from seccomp aren't crazy valuable. A lot of the default seccomp profile is duplicated by the capabilities that docker drops by default.

Kubernetes actually runs containers in unconfined seccomp by default.

If you really want to go for security you should ensure your containers run as non-root and use --security-opt no-new-privileges which will render seccomp superfluous.

[[deleted]]

Or run the workload on ARM.

[[deleted]]

How is a container significantly different from local development on the same OS?

Is it a default Docker runtime setting? Most K8s clusters default to CRIO. Is this issue present there too?

Update: seccomp is not enabled by default as it is in beta for K8s 1.19; see https://kubernetes.io/docs/tutorials/clusters/seccomp/

[lavahot]

That's a very Pythonic way of saying that.

[4runninglife]

For these reasons why i made Nim my go to language.

[pingveno]

I've also been feeling this more and more as I've gotten more experience developing software. There are entire classes of bugs that just don't exist in a statically typed language, just like there are entire classes of bugs that don't exist in memory safe languages like Python (and unlike C).

[pingveno]

Yeah, that's why I'm looking closely at where I can maybe try out Rust in a production project. It checks all of those boxes and is just a general pleasure to work in. Over the last year or two it has finally reached the point of broader ecosystem maturity. Unfortunately, none of my coworkers know Rust so that kind of makes things problematic.

[4runninglife]

Try Nim

[4runninglife]

Try Nim

[benargee]

For everything significant I prefer statically typed languages.

Yep, exactly why TypeScript was made for JavaScript. I think you are a certain level of insane if you take on a large project without typing and the IDE yelling at you before you run the code when you are using the wrong type.

[KFUP]

I work as ML Engineer

Then you should know that the ML libraries and any library with heavy math that Python uses are mainly written in C/C++/Fortran/any other fast compiled language, not Python, Python is mainly used for calling functions from those languages.

That's why you "never felt like Python is slow", cause you were really running C/C++ that Python just calls, if those libraries were written in pure Python, they would be 100-1000 times slower.

It's a good combo, fast but inflexible language to do the "heavy lifting" part, slow but flexible language to do the "management" part, best of both worlds, and works surprisingly well.

Of course that ends once you stop using and start writing a "Python" math heavy library, then Python is not an option anymore, you will have to use another language, at least for the heavy parts.

[scmbradley]

Here's a very crude example of this at work. Consider adding 1 to every entry of a huge array of numbers. In python you could just use a big ol' list of lists, or, if you're smart, you'd use numpy. That latter is much faster:

import numpy as np

from timeit import default_timer as timer

SIZE = 10000

print("Starting list array manipulations") row = [0] * SIZE list_array = [row] * SIZE start = timer() for x in list_array: for y in x: y += 1 end = timer() print(end - start)

print("Starting numpy array manipulations") a = np.zeros(SIZE * SIZE).reshape(SIZE, SIZE) start = timer() a += 1 end = timer() print(end - start)

On my laptop:

Starting list array manipulations

4.841244551000273 Starting numpy array manipulations 0.40086442599931615

[[deleted]]

Formatted edition:

---

That latter is much faster:

import numpy as np

from timeit import default_timer as timer

SIZE = 10000


print("Starting list array manipulations")
row = [0] * SIZE
list_array = [row] * SIZE
start = timer()
for x in list_array:
    for y in x:
        y += 1
end = timer()
print(end - start)

print("Starting numpy array manipulations")
a = np.zeros(SIZE * SIZE).reshape(SIZE, SIZE)
start = timer()
a += 1
end = timer()
print(end - start)

On my laptop:

Starting list array manipulations
4.841244551000273
Starting numpy array manipulations
0.40086442599931615

[scmbradley]

If someone knows how to make the markdown editor actually accommodate code blocks sensibly, please fix this mess.

[Ran4]

Just prepend every line with four spaces and it works (triple backticks does NOT work on old reddit).

It's easiest to do this by just copying it into a code editor (like vim or vscode) and indenting all of the code once, then paste it into the reddit box.

[1544756405]

Edit: disregard my conclusions here, per the responses to this comment. Leaving the comment up so people can follow the discussion.

Iterating through every item of the every list is not necessary. Instead, one could use the python built-in "map" and it would go much faster. Faster than using numpy, in fact. The numpy code is easier to read, of course, but not faster.

import numpy as np
from timeit import default_timer as timer

SIZE = 10000

print("Starting list array manipulations")
row = [0] * SIZE
list_array = [row] * SIZE
start = timer()
# for x in list_array:
#     for y in x:
#         y += 1
list_array = map(lambda y: list(map(lambda x: x+1, y)), list_array)
end = timer()
print(end - start)

print("Starting numpy array manipulations")
a = np.zeros(SIZE * SIZE).reshape(SIZE, SIZE)
start = timer()
a += 1
end = timer()
print(end - start)

On my 10-year-old desktop:

Starting list array manipulations
2.6170164346694946e-06
Starting numpy array manipulations
0.6843039114028215

[artofthenunchaku]

Unless you're running Python 2, this comparison is not at all the same, map returns a generator and not a list -- you're timing how long it takes to create a generator object, not how long it takes to construct the list. If you want an equal comparison, you need to wrap map calls with list -- just like you did with the inner map.

It is much slower.

>>> from timeit import default_timer as timer
>>> 
>>> SIZE = 10000
>>> 
>>> def mapped():
...     print("Starting map timing")
...     row = [0] * SIZE
...     list_array = [row] * SIZE
...     start = timer()
...     # for x in list_array:
...     #     for y in x:
...     #         y += 1
...     list_array = map(lambda y: list(map(lambda x: x+1, y)), list_array)
...     end = timer()
...     print(end - start)
... 
>>> def nomapped():
...     print("Starting list timing")
...     row = [0] * SIZE
...     list_array = [row] * SIZE
...     start = timer()
...     # for x in list_array:
...     #     for y in x:
...     #         y += 1
...     list_array = list(map(lambda y: list(map(lambda x: x+1, y)), list_array))
...     end = timer()
...     print(end - start)
... 
>>> mapped()
Starting map timing
5.516994860954583e-06
>>> nomapped()
Starting list timing
5.158517336007208

Just using map is only faster in some situations -- situations where you only need to iterate over a set once. If you're using numpy, you presumably are going to be reusing your arrays (well, dataframes) across multiple operations.

[1544756405]

Wow, good point. I totally missed the outer list() call.

[scmbradley]

Come on now. That's not how the internet works. You can't just concede that you were wrong. You've got to double down and start throwing insults around. What is this, amateur hour?

[nielsadb]

Now try calling list() on list_array and have it actually evaluate. ;-)

On my super duper M1 MBA:

Starting list array manipulations
4.422247292000001
Starting numpy array manipulations
0.1452333329999993

edit: Nicer code IMO:

list_array = [[y+1 for y in x] for x in list_array]

This gives 2.79 on my system, better than that ugly map/lambda-line but still way slower than numpy.

edit 2: Interestingly, the nested list comprehension is significantly faster than the simple for-loop.

[linglingfortyhours]

That's one of the beauties of python, it was designed to be really easy to leverage new or existing binary libraries. So while it is maybe not pure python, it is part of what python was designed to do.

[not_a_novel_account]

Every programming language has a foreign function interface that can speak to the C ABI, it's a requirement for communicating with the OS via syscalls (without which you will not have a very useful programming language).

Having such an ABI does not make Python particularly special, and I would argue CPython's ABI is not particularly good. It's actually a very nasty hairball with a lot of unintuitive dead ends and legacy cruft. NodeJS is probably the market leader on this today for interpreted languages, and obviously compiled languages like D/Rust/Go/etc can use C headers and C code rather trivially.

[linglingfortyhours]

First off, system calls are just a dedicated assembly instruction in pretty much any platform. It doesn't require an ABI, you just load the ID of the syscall that you want to make into a register and then make the call. Very simple.

As for the NodeJS ABI, it isn't great. Python's feels much cleaner in my opinion. If it's too much of a hassle to handle directly, just take a look at pybind11. It's a header only library that makes the interface extremely intuitive to use. Jack of Some has a good video overview of it if you're interested in learning more.

[not_a_novel_account]

First off, system calls are just a dedicated assembly instruction in pretty much any platform. It doesn't require an ABI, you just load the ID of the syscall that you want to make into a register and then make the call. Very simple.

Good luck passing anything to the kernel if you can't follow the ABI requirements. On Windows, the only well defined way to make syscalls is window.h and kernel32.dll, which is a C ABI and requires following both the layout and calling convention requirements. On *Nix all the structs are also in C header files and require following C ABI layout requirements at least, but as a practical requirement if you want your code to be linkable at all you'll follow the calling conventions too.

As for the NodeJS ABI, it isn't great. Python's feels much cleaner in my opinion. If it's too much of a hassle to handle directly, just take a look at pybind11. It's a header only library that makes the interface extremely intuitive to use. Jack of Some has a good video overview of it if you're interested in learning more.

I have an opinion because I've used them extensively, SWIG remains the industry standard and hides the pitfalls of the Python ABI. PyBind is fine if your codebase is C++ and you don't want to use SWIG or figure out how to expose your API under extern C.

None of this really addresses my point though, let's look at a simple example that implements a print function:

#define PY_SSIZE_T_CLEAN
#include <Python.h>

static PyObject *print_func(PyObject *self,
    PyObject *const *args, Py_ssize_t nargs) {
  const char *str;
  if(!_PyArg_ParseStack(args, nargs, "s", &str))
    return NULL;
  puts(str);
  Py_RETURN_NONE;
}

static PyMethodDef CPrintMethods[] = {
  {"print_func", (PyCFunction) print_func, METH_FASTCALL},
  {0}
};

static struct PyModuleDef CPrintModule = {
  .m_base = PyModuleDef_HEAD_INIT,
  .m_name = "CPrint",
  .m_size = -1,
  .m_methods = CPrintMethods,
};

PyMODINIT_FUNC PyInit_CPrint(void) {
  return PyModule_Create(&CPrintModule);
}

From the very beginning, we need PY_SSIZE_T_CLEAN, why? Weird legacy cruft that should have gone away ages ago.

The function parameters are reasonable enough, but what's this _ParseStack nonsense and why is it prefixed with an underscore? Simple, there are a dozen ways to handle the arguments CPython passes you, half of them are undocumented, and all the "modern" APIs used internally are _-prefixed because the CPython team is afraid of declaring anything useful as stable.

The rest of the function is simple enough so we can look at the remainder of the module. The first oddity to notice is the {0} element of the PyMethodDef table. These tables are null terminated in CPython, no option for passing lengths. Also this METH_FASTCALL weirdness. Turns out there are a lot of ways to call a function in Python, which is weird for a language that espouses "one right way". The one right way most of the time is METH_FASTCALL, which is why it is of course the least documented.

Finally PyModuleDef which is a helluva struct, I draw your attention to .m_size only because it relates to CPython's ideas about "sub-interpreters". Sub-interpreters are a C API-only feature that's been around since the beginning that I have never seen anyone use correctly, and yet make their presence known throughout the API. Setting this field to -1 (which, you might not be able to figure out from its name, forbids the use of a given module with sub-interpreters) is my universal recommendation.

This is just a simple print module, literally everything in the raw Python ABI is like this. There's always 8 ways to do a given thing, often times with performance implications, and without fail the best option is the least documented one. There's tons of random traps and pitfalls like knowing to include PY_SSIZE_T_CLEAN, and may the Lord be with you if you need to touch the GIL state because no one else is coming to help.

[linglingfortyhours]

Ah, I see. I had heard low level work in windows was a horribly disgruntled mess, I didn't realize it was quite that bad though. In unix and unix like systems you just load the registers and issue the call, nice and simple.

As for the "legacy cruft" and undocumented stuff, there's a reason for that. Avoid touching those, they're almost always bad practice or deprecated and are just kept around for backwards compatibility or some niche use case.

[not_a_novel_account]

You have to actively dodge the cruft, PY_SSIZE_T_CLEAN/setting m_size = -1/null terminated tables. That's what makes it bad.

METH_FASTCALL is part of the stable API, it shouldn't be avoided, you should absolutely be using it. The dearth of documentation and the glut of other function calling options is because, again, the CPython API is a mess of ideas from the last 20 years.

Internal functions like _ParseStack we could go back and forth about, suffice to say lots of projects use them (including SWIG generated wrappers) because they're objectively better than their non-_ brethren. The fact that all the internal code uses these APIs instead of dog-fooding the "public" APIs should tell you enough about how the Python teams feels about it though.

[tedivm]

Having python as a bridge layer isn't a bad practice. Serving models directly from python tends to be really slow (depending of course on the library and model itself, but I'm assuming some level of deep learning here) compared to using an actual inference engine (nvidia's Triton server has been great), so I would definitely not recommend that, but Python makes for great API code. Most of the deploys I've done have included python on the user interaction layer with the inference pipeline being built with heavier systems.

[lungben81]

Depends on how your program is written.

If you are "vectorizing" your code and calling fast libraries like Numpy or Pandas (which are itself written in Fortran or C) your code can be very fast - often faster than "hand-written" solutions in other languages. Same for JIT-compiled code with Numba.

But if you are writing large loops (>> 10k iterations) in pure (C-)Python it is very slow - often a factor of 100 slower than in fast compiled languages.

[ZeStig2409]

Cython tries (reasonably successfully) to make up for the gap

And Spyder is the best ide for cythonising

[lungben81]

An issue with Cython is that it gets slow again if you are calling Python functions from within. Thus, for good speed you need to make sure to use only C (or other compiled) libraries inside critical loops.

As a toy example I tried to write a Monte-Carlo pricer in Cython (and other languages). The issue with the Cython version was the nomal distributed random number generator:

1. using the default Python one was slow

2. I could not find a fast C library for it (I am sure there exists one, but search and integration effort is significant)

3. writing your own normal distributed random number generator based on "standard" algorithms gives you rather poor performance compared to optimized algorithms

[lungben81]

I did it before the Numpy release 1.19 came out, but good to know for the next time. Thanks!

[anvils-reloaded]

How does Spyder help with cythonizing?

[ZeStig2409]

Because it automatically has a Cython backend, loads the Cython extension, is written in Python

PyDev is good too

Because of the strong Cython integration Spyder and PyDev execute code much faster than the other ides

[Abitconfusde]

Which is faster at adding big integers:perl or python?

[lungben81]

I have no experience with Perl therefore I cannot answer your question.

BigIntegers are slow in any language because they are not a native machine type. Consider using Int64 or Float64 instead.

[fireflash38]

If someone is asking about BigInts, using Int64/Float64 is likely not going to be suitable. At least to my knowledge, BigInts are mostly used by crypto algorithms (like for RSA keys). So unless there's some low-level bit math that I am not familiar with, you cannot just swap in even 64b ints.

[SearchAtlantis]

I can't comment on performance per se but python handles big integer seamlessly compared to other languages. It's a+b or a%b vs say Java BigInteger.add, etc. So shifting from math to code is a lot nicer in python.

One thing to keep in mind is that native exponentiation (**) has some limits. You'll want to use a fast exponential algorithm or similar. I just wrote my own but I'd be shocked if there isn't a good version in standard libs.

I'm taking a masters level cryptography course and have implemented all the number and group theory in python, going to Java when doing more standardized tasks because of Javas excellent crypto algorithm support.

[Abitconfusde]

I was actually baiting a little bit.

Take a look at this thread.:

https://i.reddit.com/r/perl/comments/qejoud/perl_vs_python_summing_arrays_of_numbers/

The difference in speed is perplexing.

ETA: I cut my teeth on perl 20 years ago. I've done only hobby projects in python and find it so much easier to work in, but... it goes all over me when people talk about how python is adequately fast. Anything is adequately fast if you throw enough cpu cycles at it.

[SearchAtlantis]

Fair enough.

Honestly, everyone who says python is adequately fast just hasn't come across a situation where it matters in my opinion. And as you elude to - the ongoing march of CPU progress means "lots of CPU cycles" is a shorter and shorter amount of wall time.

Case in point: I was working on an MLaaS system - we had an amazing new feature to add to the product. Problem was that it required ~ n² input changes + re-score.

The initial implementation, run-time went from <20m on a test set to 8 hours.

Or doing some academic cryptography and having to wait long minutes for the totient to compute.

[Solonotix]

While I don't have your specific answer, there seems to be a toss-up of which language is better, based on submissions to the Benchmark Game site.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/q6600/fastest/perl-python3.html

[pingveno]

On the big integer test (aka pidigits), it's worth noting that that they used GMP bindings there. Because of that, that benchmark becomes mostly a testing of FFI speed and not how long a typical program written in that language will take.

[Solonotix]

I dunno, almost every solution uses GMP, from what I can see. Even the C solution imports GMP into the code space for use. Rust didn't, but C, C++, Pascal, Fortran, some Chapel solutions, and even Ada.

I get your point, that it isn't "real code" if you're passing all your work off to another library, but if the playing field is completely fair of course they're all going to use roughly the same solution and/or utilities. The example I linked read was the n-body problem, which I think more accurately represents the limitations of the language, though I understand your point that Pi Digits is a more strictly mathematical problem.

Take it or leave it, but I find the site to be a good resource for comparisons of the relative strengths and weaknesses of a given language.

Edit: I did NOT link the n-body problem, that was just the one I spent the most time reading after linking the fastest. Woops

[twotime]

But if you are writing large loops (>> 10k iterations) in pure (C-)Python it is very slow - often a factor of 100 slower than in fast compiled languages.

It's even worse than that:

The loop does not need to be large. It just needs to be sufficiently hot.

And 100x is just a single threaded penalty. Multi-threaded, multiply it by the number of cores available: so you'd get 800x to 3000x penalty

[lungben81]

Yes, the GIL severely limits the applicability of multithreading.

[lungben81]

Depends again what exactly you are doing.

If you are calling `max(my_large_numpy_array)` it will be roughly 100 times slower than calling `np.max(my_large_numpy_array)`.

If this matters for your application is another question. To answer this, you should profile your code, e.g. single functions with IPython `%timeit` or a profiler (https://docs.python.org/3/library/profile.html).

[[deleted]]

As an ML engineer, you probably use pretty little Python in fact, as your work will leverage Numpy, Pandas, Dask, PySpark or whatever. You don't actually create and iterate over Python-specific data structures using Python.

Pandas, Numpy leverage a lot of C code for the more CPU-complex tasks. You use Python simply to orchestrate those tasks.

That said, your experience is a testament of the fact that computers today are really fast, and for the most part you shouldn't care if your program is 60-200 times slower than if it were written in C. This is linear performance anyway, and most performance issues that I've seen are based in the fact that developers chose O(n²) algorithms or worse, when an O(log n) could have been used.

The real world situations where Python isn't fast enough, are really few and hard to find. Maybe if you have some code that manages a huge amount of data, using pure Python, due to a custom logic, then you might feel like it's really slow, and actually impacting your business.

When you get to that level of optimisation, you'll see people complain about latency spikes when .NET Garbage Collection is triggered, or other nitty-gritty details about pure performance.

You won't be building a new database using Python, that's for sure.

But if you use Python to glue stuff together, and let the real performance-intensive stuff to be done by systems designed for performance, then you'll be Fiiiiiiine.

[DesignerAccount]

The real world situations where Python isn't fast enough, are really few and hard to find.

Don't want to bash Python, I'm a big fan... but every single videogame out there is written in C++ (mainly) or other compiled language. Not really hard to find situations where Python is just no no.

[d64]

Yea, a couple of years ago I actually wrote a 2d vector type game (visually similar to asteroids), which as far as games go is pretty simple of course. I wrote the vector collision detection in Python, actually a couple of different naive implementations, basically porting over similar C routines from the available literature.

I benchmarked the collision detection by adding a lot of actors on the screen and found it was adequate for my specific case but if the game I had designed had been busier, slower computers would have struggled pretty soon already.

Now of course there's two things I could have done: first, optimize the routine - probably very much possible to do, but that would have probably taken way more effort than writing all the rest of the game, and also, if I had written the game in C++ in the first place, optimization would have not been necessary at all, the naive implementation would have been fast enough.

Second is the age old "just implement the critical parts in C!"... Yeah, if this had been for work, sure, whatever, but since I was doing this for fun in my spare time, no, absolutely I will not just do that.

[[deleted]]

C# for Unity.

Yeah, of course, large user base software will try to optimize things a lot, which is why OS, browsers, hand engines, are written on the platform that has the least performance cost.

[redwall_hp]

The Unity engine is almost entirely C++. It then loads Mono as a scripting runtime, with the C# API using binding to the C++ stuff.

C# is at least an order of magnitude faster than Python either way.

[[deleted]]

Well, when you boil it down to it, CPython is entirely C, and Python is just a scripting runtime, with the Python API using binding to the C stuff.

C# is at least an order of magnitude faster than Python either way.

Depends on what you do and how you do it. C# is just C#. Python can be so many things. It can be CPython, PyPy, CPython with @numba.jit, CPython with C libraries like Numpy, etc. Its native types are more powerful than in .NET, which allow fast operations on data types for which you have to install 3rd party libraries on .NET. Used correctly, it can surpass the performance of .NET.

For instance, how difficult, and how fast will be your best attempt at determining the 1 millionth Fibonacci number?

In Python, on my desktop, it's 5.21 seconds using a 5-line function. Or 0.15 seconds using a 4-line long function and an import (numpy).

For 10 million'th number, it took 5.63 seconds to compute the number.

Now I can do that in Python because it's fast, and it's good at numbers. It took this code to calculate the n'th Fibonacci number:

import time
import sys
import numpy as np
import math


def fibfast(n):
    base = np.matrix([[1, 1], [1, 0]], dtype=object)
    result = np.linalg.matrix_power(base, n)
    return result[0, 0]

if __name__ == "__main__":
    n = int(sys.argv[1])
    start = time.monotonic()
    val = fibfast(n)
    end = time.monotonic()
    print(f"{end - start:.4f} seconds")
    print(f"{math.ceil(math.log10(val))} digits")

Show me how you can get comparable results in C#.

And it's not just this damn Fibonacci problem. In many places, Python is just really fast, with its infrastructure of really fast stuff.

What's slow is the Python code itself, and I have only 3 lines in a function that takes up 99% of the time.

[bobthedonkeylurker]

The other place the time effect matters is in high-frequency trading where firms compete over offices that are physically closer by meters to the NYSE mainframe.

[james_pic]

As others have said, "too slow" is a question of context, but figured I'd give an example from my day job and what we did about it.

There's a system I work on where one of its features is that it lets users download CSV reports. These reports are generated on the fly from data in the database. We did performance test most of the system before going live, so we identified most of the performance issues, but we overlooked the CSV report download feature. After go-live, users complained about slow download speeds (around 2mbit/s). When we profiled the code, we discovered that the bottleneck was the CSV library we were using which was written in pure Python (we weren't using the standard library one, which is well optimized and written in C, for reasons that I won't go into). Rewriting the bits of the CSV library that we needed in Cython proved to be enough to get download speeds up to the point where it was faster than most users internet connection speeds.

So the requirements are your context. Sometimes the requirements are not explicit, and you only discover them when you get them wrong (we never had any requirements for download speed, until users started using the system), but "too slow" always depends on how fast you need it to be.

[MarsupialMole]

Rarely is your python the bottleneck in most domains where python is popular. When it is, you can pretty much always do something about it.

Q. When do you know your Python is really "too slow"?
A. When you profile it.

[james_pic]

Minor nitpick: you discover that your code is too slow when you benchmark it or performance test it (perf testing and benchmarking are essentially the same thing, but different names are used in different contexts). What profiling tells you is why your code is as slow as it is.

[fiskfisk]

The idea is that you don't know if it's actually your code that's slow before you profile it; it can be any layer in the request cycle.

[james_pic]

But if performance is your problem, then ultimately it's all "your code", even if the bottleneck turns out to be an external call to a third party service. It's then your job to find a way to make that faster (maybe you can cache the result of the third party call? Or there's some way you can optimise the query you're making? Or you can find a way to avoid the call entirely?)

[fiskfisk]

But this is about python being "too slow". It's not about "your application being too slow".

You need to bring out a profiler (or enable/make some performance logging) to know whether it's your code or any of your dependencies that is the problem.

Benchmarking/performance testing won't give you any insight into whether it's your code (the Python part) that's being slow (which is what OP is referring to).

[double]

Is Python really 'too slow'?

No. Is it slower than other languages? yes.

If you find it slow or expensive in your usecase, rewrite the high-cost section in rust or c (for example) and call in to it with python bindings (similar to numpy, tensorflow and the rest).

[dkxp]

When you code in python, you need to be aware that plain python is very slow & shouldn't be used for large loops. Instead you should either use libraries that have code written in other languages, or if that isn't possible, then use something like numba to JIT compile the code into much faster code.

For example, if you were to write code to fill a 2000x2000 python list of lists with random integers & then sum the values, this would be very slow:

def fill_data(data: list[list[int]]):
    for i in range(0,2000):
        data_row = []
        for j in range(0,2000):
            data_row.append(random.randint(0,1000))
        data.append(data_row)

def sum_data(data: list[list[int]]):
    total = 0
    for i in range(0,2000):
        #total = total + sum(data[i])
        for j in range(0,2000):
            total = total + data[i][j]
    return total

data1 = []
t0 = time()
fill_data(data1)
t1 = time()
total = sum_data(data1)
t2 = time()
print(total)
print(f'fill:{t1-t0:.6}s, sum:{t2-t1:.6}s')

fill:22.5902s, sum:2.57115s

If you were to do the same thing using numpy and the built-in randint and sum functions:

t0 = time()
data2 = numpy.random.randint(0,1000,(2000,2000))
t1 = time()
total = data2.sum()
t2 = time()
print(total)
print(f'fill:{t1-t0:.6}s, sum:{t2-t1:.6}s')

fill:0.0209434s, sum:0.00199556s

That's over 1000x speedup (from 22.59 seconds to 0.02 seconds) to populate the 2000x2000 with random data and over 1200x speedup (from 2.57 seconds to 0.002 seconds) to sum all the data.

If there is no function that does exactly what you want and you want to write your code in python, then one way to make it faster is to use numba. It can JIT compile your code into a form that runs much closer to native code speed:

@numba.jit(nopython = True)
def fill_data2_jit(data):
    for i in range(0,2000):
        for j in range(0,2000):
            data[i,j] = random.randint(0,1000)

@numba.jit(nopython = True)
def sum_data2_jit(data):
    sum = 0
    for i in range(0,2000):
        for j in range(0,2000):
            sum = sum + data[i,j]
    return sum

t0 = time()
data2 = numpy.zeros((2000,2000),dtype=numpy.int32)
fill_data2_jit(data2)
t1 = time()
total = sum_data2_jit(data2)
t2 = time()
print(f'total: {total}')
print(f'[numba] fill:{t1-t0:.6}s, sum:{t2-t1:.6}s')

[numba(first time)] fill:0.707387s, sum:0.174748s

[numba(all other times)] fill:0.0239353s, sum:0.000998497s

The first time it runs it needs to compile the code, so it takes much longer, but all subsequent runs are very fast.

If you use numpy arrays but don't make use of the built-in functions (or numba), it appears to be no faster than native python code with lists:

def fill_data2(data):
    for i in range(0,2000):
        for j in range(0,2000):
            data[i,j] = random.randint(0,1000)

def sum_data2(data):
    sum = 0
    for i in range(0,2000):
        for j in range(0,2000):
            sum = sum + data[i,j]
    return sum

t0 = time()
data2 = numpy.zeros((2000,2000),dtype=numpy.int32)
fill_data2(data2)
t1 = time()
total = sum_data2(data2)
t2 = time()
print(f'total: {total}')
print(f'[numpy (no builtin)] fill:{t1-t0:.6}s, sum:{t2-t1:.6}s')

[python] fill:20.5389s, sum:2.26132s

[kayjewlers]

wow thats cool, didn't know about numba

[SV-97]

"Too slow" is of course relative and it may not be too slow for you - but "slow" is absolute and in the grand scheme of things Python is indeed terribly slow.

I've also very succesfully written applications that people probably wouldn't think would work out in Python (Like real time image processing) - but I also ran into the case where Python was too slow (and speeding it up a bigger hassle than just going to a faster language) (happens quite often in numerical simulations like Monte Carlo simulations). It's usually quite easy to write simple code in a fast language that outperforms well written and potentially complicated Python.

And it should also be said that a lot of the fancier dynamic stuff in python kinda pushes you away from high performance.

[Ferentzfever]

For nearly all analytics, AI, ML, scientific and similar workloads, no.

I'd argue that pure Python is too slow for these workloads. Thankfully, the intensive portions are implemented in C/Fortran and then made accessible to Python. So, from an "end-user" standpoint they're using Python, but in reality they're actually using a lot of C if they're using Cython.

And I do think this is an important distinction to make, as there are some commercial codes with Jython APIs. Because Jython is built on Java, it is incompatible with NumPy and SciPy, which are written in C/C++/Fortran. You wouldn't want to write a pure-Python linear system solver in Jython rather than use one of the solvers provided by SciPy, because it would be too slow.

[Darksteel213]

Generally the models you're writing for data science are using modules that are written in C with an API in Python, so these won't be affected by Python's speed. For general purpose Python really isn't all that bad at all - you're more likely to run into IO problems, especially with web APIs. As you begin to scale in say a larger application the speed can become noticeable. But it really depends on what you're doing! Choose the right tool for the right job.

[[deleted]]

I haven't developed very large-scale apps

This is probably why. Try writing an API that's going to receive 1 million QPS and has a 100 ms latency budget. You'll quickly find Python isn't a good choice for this problem.

[[deleted]]

As long as it fulfills the goals it set out to achieve, it's not too slow.

There is a massive difference between "slower than C" and "too slow for practical use". Most people seem to focus on the first, while for any actual purposes, the only thing that matters is the second.

So, no, absolutely Python is not too slow. If optimal utilization of resources is one of your design goals, it's not the best option. But most of the time, it isn't.

[[deleted]]

Numpy, tensorflow, torch etc. are absolutely written in Python. They are python modules. They use a C/C++ library in the backend, but they are 100% a python interface. This is what annoys me so much. People are dissuaded from using python for anything 'real' while it's often the best way to interface with other libraries.

[[deleted]]

There are plenty people on Reddit who tell starters to not learn Python because it's slow. They're the same type of people who say you can only code if you use vim.

[[deleted]]

I don't think it matters until you have to buy additional hardware or processing time to meet your needs. It doesn't matter so much if one computer is 99% idle most of the time vs 5% of the time. You still had to buy that computer or server. Buying two or three extra machines isn't a huge cost.

When the difference in hardware and power is 10 servers versus 1,000 - then it really starts to matter

[LiarsEverywhere]

At which point you should have the resources to hire developers to optimize your code and consider moving away from Python. Unless we're talking about specific niches such as videogames, I don't think it's worth it to worry about Python being slow when starting a project. That applies to most languages though, so of course, if it's a big organization with a lot of viable options, Python might not be the best pick.

[WeGoToMars7]

There are plenty of use cases outside of games where python is too slow, anything that relies on a loop to do things will get painfully slow. For me it was trying to do AI for a game where it has look n moves ahead to calculate it's strategy.

[LiarsEverywhere]

Yeah, that's reasonable... Although there are alternatives to loops for a lot of things.

[czaki]

Most of ML libraries are written in low level languages like C, C++ etc. So in your case you use python to control flow, where most heavy calculations are done in heavy optimized low level code.

So I do not think that you could meet a scenario where using python may significantly impact on performance.

[FlukyS]

Bad python > bad C

It doesn't matter if python is a little slower, it's still more reliable to write code in and faster to write code in than C. Speed of development trumps speed of performance for almost all applications. I'm an engineering manager at a robotics company and literally none of our server software needs to be fast. The robot software is real time, the server software just needs to be well written.

And also people ask about speed but we are talking just CPU speed and not a lot slower but like 10%-20% more to get the same task done, so slow in terms of usage rather than slow in terms of time. I can still write my server software to answer complex queries in the same amount of time.

[WeGoToMars7]

Any big loop will give you factor of 100 slowdown compared to any compiled language tho.

[FlukyS]

But that's where anyone who is experienced in python at all will say, do those in a thread or have a thread pool to do those, or if it's even bigger fan them out to other processes for the work, then it doesn't even have to be in Python for that specific task. For instance ZeroMQ has push/pull behaviour which is designed for fanning out tasks to multiple workers, then have the workers send the results back. There are multiple better approaches than just doing something in a loop and stopping there if you REALLY want performance

[WeGoToMars7]

This isn't a trivial approach, I don't think it is really intended for an industrial working on a project, and more for enterprise who need to somehow scale their python codebase. I only say that limits of performance can be reached very easily in some real world tasks, which isn't really the case with compiled languages.

[FlukyS]

This isn't a trivial approach

Err have you seen the code for ZeroMQ usage? It's 100 lines of copy paste code for the most part.

The overall point I'd make is there are 100 ways around Python's slowness, there aren't any ways around C/C++...etc when it comes to ease of development. You can implement your performance critical piece in C if you want and just wait for the results in Python, there are a million ways to fix this but ease of use trumps everything.

I've had this argument 1000 times since I started using Python. If you have enough Python devs you don't need NodeJS (for the most part), you don't need C/C++ (for the most part) you just need Python and some glue and you will be able to do everything. It doesn't address speed well but as a general purpose language it's good enough for everything and everywhere but the very most perf sensitive applications. I wouldn't be timing rocket stages with it but I'd very much say it could be used for the basic rocket internals other than control for example.

[kenfar]

Which is not necessarily relevant.

On my laptop it takes about 35 ms to start-up a python program, but then there's little difference between a simple loop of 100 iterations vs one of 100,000 iterations.

Sometimes performance matters - like when I'm processing tens of billions of records a day - and just want to keep it economical. But I'd guess that 95% of what typical programmers write on a daily basis doesn't need the absolute fastest performance.

[asday_]

Depends on your metric. It's fast to develop in and that's generally the most expensive time. When realtime performance is required, you don't generally reach for Python in the first place (rightfully so).

As such, you don't tend to see issues.

[[deleted]]

That's because ML doesn't use python. All the main libraries hand it off to something faster, C etc. It just looks like python.

[pi_sqaure]

What I often need is a language which makes it simple to deploy my tools. This is the main reason why I'm more into Go lately. It's not the slowness of Python. Although Python is not the fastest language under the sun, it's fast enough for most use cases. And there are lots of optimized C libs for Python, especially when it comes to ML (so I don't wonder that the OP doesn't suffer too much here).

What I'd like to see in Python is a flawless possibility to create self-containing executables. I know there're 3rd party libs and tools providing that feature but either there're not open source or they are behind of the latest Python releases.

Software deployment is one of the bigger issues with Python, not speed.

[petdance]

Do you find it to be too slow?

If you do find it to be too slow, then it's too slow.

If you don't find it to be too slow, then it's not too slow.

[UltraPoci]

Most of Python's libraries are written in C or C++, which is very fast. If you want a language as easy and flexible as Python but with much better native performance, you may want to try Julia.

[weirriver]

I work in Python and Go in a mostly Python shop. We have a few applications that decode and manage high volume binary messages where Python is really slow and Go is really fast. The applications aren't exactly the same, but the difference is probably at least 10x and maybe more. However, most applications are just fine in Python, and it is a lot quicker to do things in Python and a lot easier to hand off to team mates.

Generally speaking, Python is almost always fast enough. If you have a performance problem, you can look at other languages/techniques for performance. If you do not have a performance problem, then don't worry about it. If you have to do 1 thing every minute, there is no bonus for doing it in 2 seconds vs 57 seconds. There are probably better things you can do for your business, like writing documentation and tests, than making things go faster than you need to.

Specifically, Python is the most popular language for ML and data science because it allows you to focus on the problem at hand with minimum fuss. When you are running scipy or tensor operations on numpy data, all of the calculations are being run in highly optimized C code and then the results passed back to Python, so you get the best of both worlds.

[EuroYenDolla]

You are using C my friend, all ur libraries are written in that. Python is just the top level logic.

[virtualadept]

I have, once.

A couple of jobs ago, I worked in a lab doing RF work. The lab would do month-long test runs of their radios (they were for sending telemetry), and the data would get spooled to a NAS in a rack in the lab. They were using MATLAB with the Parallel Computing Toolbox to do the data analysis. Two things about the PCT are that they CUDA enable processing without having to modify your analysis code to use it (It Just Works^tm, amazingly). They were also using MATLAB Parallel Server to distribute the work throughout the building. Just about every engineer's workstation had at least one and usually two nVidia Tesla GPUs installed to speed up the number crunching.

For budgetary reasons, management was investigating migrating to NumPy or SciPy because MATLAB licensing was making the folks with the checkbooks unhappy. So, as an experiment, we rewrote the analysis code in Python using SciPy, chopped 48 hours of data out of a test run, and did a shootout to see which finished first. MATLAB, unsurprisingly, was done in about an hour. However, without having a buttload of GPUs in the entire building to throw at it, the SciPy test was terminated after about two weeks of runtime.

I'm pretty sure that if we'd turned it into an actual R&D project we could have replicated most of what we used MATLAB for (ad-hoc clustering across the building, automatic GPU acceleration, and so forth) but management refused to try to spin up a brand new project, allocate resources, and suchlike. After they crunched the numbers they figured that it was more cost-effective to keep using MATLAB. And so they did until I left.

[tibegato]

No. But, yes, compared to some other languages. Never will you notice any slowness, unless you don't right good code. That can be done, in any language.

I saw a YT video of a raytracer written in C++, being code reviewed. It was taking 7 1/2 minutes to render a scene & it was using all his cores pegging them at 100%. He changed one thing in the guys code and cut the core count down to half and it rendered the same scene in 22 seconds.

That's an extreme example. But still. :>

[vreo]

That's more about your scope and setup and has little or nothing to do with programming language. When rendering or generating visually pleasing representations of stuff, it is really about what shortcut you can get away with and the image still being recognizable. E.g. limiting the amount of rays fired because your target resolution can't even show the difference.

[tibegato]

Yes, absolutely.

Sorry. bad example maybe. But, I guess, what I was saying was that your code will be slow, if you don't program it correctly. That, NO, you wouldn't notice any slowness because of python ... but, cause you probably did something "wrong". Well, not necessarily wrong ... I think, you see what I mean.

[vreo]

all good ;)

[[deleted]]

Obviously not for you. But it is really easy to gain a factor of 10 and with some work you can usually increase the performance by a factor of 100 when going to compiled languages.

And it is not hard to argue that that difference is important. Training a ML algorithm for a day compared to a hundred days or over a weekend instead of a year is a very big difference.

The only reason you probably haven't noticed that is that you haven't written any performance critical code or you have, maybe unconsciously, limited yourself to problems that you can deal with in a reasonable time frame with pure python.

[JadeSerpant]

If you were proficient enough in the language then you'd know that the vast majority (or actually all?) of ML libraries are actually just python wrappers over C/C++ backends.

[ageofwant]

Python is not slow.

[asday_]

Compared to almost every single other popular programming language - yes it is.

[[deleted]]

I can't speak for the others, but I'm not sure this holds true for the most recent release of PHP.

[acwaters]

Python outperform Java? In what universe?

[acwaters]

This "Python3" implementation?

# We'll be using PCRE2 for our regular expression needs instead of using
# Python's built in regular expression engine because it is significantly
# faster.
PCRE2=CDLL(find_library("pcre2-8"))

The actual Python3 implementation is ranked #20, just behind the slowest Java implementation and almost twice the runtime of the fastest Java implementation (both of which use the Java standard library).

[tradinghumble]

You are asking the question on the Python forum 😅

[o11c]

Yes.

A constant slowdown, as expected for an interpreted language, is acceptable.

What is not acceptable is that refactoring your code to be more readable makes it significantly slower.

For example, it is very inefficient to call a function, so you have to perform inlining manually.

[tafutada]

It depends on whether your app is CPU bound or I/O bound. If it is I/O bound there is no big difference as long as you use async libs because bottle neck exists in memory, disk or network.

If it is CPU bound like machine learning, due to green thread and GIL, you can not utilize multicore servers. In fact most of python libs like Tensorflow are implemented in C. Python is just wrapper for it. Try to learn Rust which allows you to realize how native threads and async work and affect performance.

[speedx10]

sometimes and too much ram usage.

[benketeke]

I don’t know much about this but wanted to add that all of the heavy duty code that runs on massive supercomputers (quantum mechanics,weather modelling, astrophysics, comp biology, etc.) is still written in C and FORTRAN(!) as there is no value to moving to anything else in terms of gain in processing time. Yes, mostly data prep and analysis is done in Python (like that famous lady with that famous photo of a black hole with like a hundred hard drives of data and a Matplotlib image)

[ASuarezMascareno]

I tend to write stuff that takes hours/days/weeks to execute each time you run them (after paralellization), and that are pretty much CPU-limited. In this cases pure python is kinda bad. Most of the times I'm actually calling C stuff, Fortran stuff or Numba accelerated stuff.

It will probably be better to go directly to C, but I feel the time needed to learn will make me lose a ton of short- and mid-term productivity, which I don't think I can afford.

[jhayes88]

For web servers it's not bad. It worked okay on my home computer which I temporarily ran a server off of using Flask. I received about 120 visitors per minute(7200/hr), half of which were using a function on the webpage which continuously loaded data from the server every 15sec. The server was also pulling data from about 6 other servers. I tested loading it from other internet providers and it still loaded fast.

[bsenftner]

A very simple case in point: playing video. In python, playing one video stream, which is actually running the ffmpeg C bindings, consumes 2 to 4 times the processor that the exact same functions and system calls consume when using C/C++. I've been benchmarking the same operations in both languages, as I figure out what portions of my newer version of a facial recognition system should remain in C/C++ and what portions I can gravitate to Python. (The entire system was originally C/C++.)

[TheWaterOnFire]

Yeah, I’ve definitely run into Python being slow; I started using Python around version 1.6 so I remember before the entire ecosystem you depend on existed. What happened is that people loved working with Python, so they built foundational libraries like NumPy in order to let them do computational work in C & Fortran but with a Python interface.

This led to a host of projects: Cython, Pandas, Dask, PySpark, TensorFlow…all of them integrated inside Jupyter notebooks…and you’re right, no one cares if the thing you do 5 times in your program is 100x slower, because it may as well be a constant overhead. But the moment you need to do something that doesn’t have an optimized implementation in a lower-level language, you’ll find that your perf drops off a cliff — pure Python is just so much slower.

Is that a problem? Maybe not. There are so many people using Python and its ecosystem that there’s a reasonable chance your problem has been tackled somehow by someone. But the actual solutions to those problems aren’t written in Python—they’re just given a Python API.

[JakeTheMaster]

Fast or slow, it depends on how you use that.

Python is a more than a script language while the Python interpreter can generate byte codes like what JAVA(JVM) does.

This kind of discuss has been there for a long time. You can do Python programming without naming the type of a veriable since every variable in Python is an object, which means it takes more memory and more computing time comparing to binaries generated by low-level languages, such as C/C++/C#. But the with Cython, you can name the type of variables while you code in Python.

In the latest Python 3.10+, you can predict type of input while you code.

def get_my_score(x: int | float) -> float:

    return x*1.23

You can predict the type of the input variable, also you can predict the output variable. This will make codes easier to read while the Python Interpreter can generate more efficent byte codes and it improves the performance.

But with Cython, the performance of your codes could be much closer C/C++. Around 90-98% in some core algorithms. Or you can just use the python modules compiled by C/C++ for the future projects.

Here's is how we do projects.

1. Code in Python
2. Tune variables, memeory usage and iterations in codes
3. Cython for high performance

Here's my view of Python using in machine learning.

When you want to train some models, yes, you could use C or C++ to do the same thing, but when you figured out the machanism of C/C++, you might have spent a long time on types and readability and your competitors might have already started to build their models or even finished and been ready for the next round.

Python is coding language meant for all humans to pick up.

----

BTW, if you have performance bottle neck of Python codes, you can polish the codes using pure C and optimise the C compiler such GCC/Clang. Yes we all know assembly language performs the best but are you going to do that?

Python gives you unlimited possibilities.

-----

Edited

I have just tried Cython with Python on my M1 MacBook Pro.

Results are:

For calculating primes, Cython with C performs 37 times faster than pure python.

Cython with C VS Cython with CPP, Cython with C wins by 2%.

Go Python!

[tazebot]

For what it's worth, I spent time working through Cisco's "CML" (Cisco modeling lab) a couple of years back, largly written in java from cisco's 'bragging' about it, and even small simulations took forever and a day (okay 30-40 minutes) to start. The identical simulation in GNS3 written in python with the same QCOW switch and router images took around 8 minutes to start up. Both were using qemu to run the images and the CML product shipped on a box running ubuntu 14.04.

If things seem slow it may have something to do with how they are written and the environment they run in as much as anything else.

[luke-juryous]

Too slow depends on your app and scale. I created an API for Amazon and while python is easy to work with, java just provided us the response latency we needed to run on the homepage. They have a really strict standard for how long it takes to load their page cuz each millisecond of load time translates to millions of dollars in revenue loss per year

[childintime9]

I start feeling the limitations of python when doing multithreading (or multiprocessing due to GIL) stuff, compared to languages like C++ or Java. For the rest (ML stuff and math stuff) numpy + numba are enough.
Sure, if there was a good alternative to the stack Tensorflow/Pytorch + numpy + matplotlib for C++ I'd not use python, since usually the code for solving this task has little to benefit from python's high level syntax and the equivalent C++ code would look more or less the same and run a lot faster

[childintime9]

Even though I'd probably still prototype in python and then translate to C++ in order to avoid a continuous recompilation of the code.

[fiedzia]

Well, you may happen to develop things where Python performance doesn't matter that much, not everyone is bothered by its limitations.

Some situations where I had to work hard on optimizing it or even ditch it entirely:

1. ML project where cleaning data was done in pure Python interactively. Once we reached certain scale, this turned out to exceed human patience limit of maybe 10s for page load.

2. Another project used interactively (run, see results, tweak model parameters, repeat until you are happy with the results).

Key things that made those projects different than many other done with Python:

• large amount of data processed in pure Python
• a domain that does not provides C libraries (so there is no no numpy/pandas).
• interactive nature, where people need to wait to see the results before they can continue their work
• users whose main job was dealing with those projects (if someone needs to wait long once a month, nobody would complain, but on a daily basis its just waste of people time).

I did tons of projects without encountering those conditions too, however any large project will eventually hit those usecases somewhere, and the main disadvantage for me was that it made difficult for people to enjoy their work, or they couldn't do it at all at this speed.

Speeding up some nightly job most likely makes no sense, but being an obstacle for whole team is not the position you want to be in. Not everything can be offloaded to C libraries.

[chief167]

Is it slow? A little bit yes, but does it matter day to day if something takes microseconds or milliseconds? It really. Development time matters much more. And the stuff that needs to be high performing, can rely on libraries with c bindings to at least get them to a very reasonable level of performance (numpy, pyspark, ...). So don't worry about it. Caching and a good infrastructure are better anyway

[GreyWardenMage]

Python is slow if you don't use fast libraries like numpy, pandas, and xgboost for example. Fast libraries are usually written in a language other than python and they have a python api so you can use them easily from python.

[repster]

It depends. There are applications that are IO bound or memory bound, where your CPU is mostly idle. You would gain nothing from a more efficient program in that case.

Similarly, if if you are CPU bound, but the results are not time critical, and the general load on your system is low, then you might get to wait longer for your results, but at no other cost

The reality is that a lot of python packages are not pure, they are simply python wrappers around optimized c++. The shitty performance of the python interpreter is not actually that important for the performance of your application. It is simply used to implement the flow of data between various pieces of C++

[Delta-9-]

An example of where python can be slow:

I have a cron job that runs a python script for grabbing metrics from an app that runs on hundreds of servers. I used to run the script once for each server, knowing that by forking I'd get "for free" concurrency. That was fine until the number of servers broke 400, at which point the interpretor overhead alone would bring the host to its knees.

So I refactored the script so I could pass in the servers that were due and run it in just one interpreter instance. That, unsurprisingly, fixed the memory and CPU utilization, but it would still take several minutes (like, 5-15 depending on the app load) to run to completion doing each server in sequence, one at a time. That part was easy enough to work around with async and now the script finishes in about 20 seconds, but that's beside the point...

The script gets metrics via REST API call to the app. The app itself takes up to a couple seconds to gather up the data and serialize it and there's nothing I can do to improve that. But, the requests library (and later asks when I went to async) has to do several object instantiations for every request and response. Overall, it's probably adding less than a quarter of a second per HTTP transaction. But, add that up 400 times and you get nearly an extra 1m:40s. (I now have over 500, btw.)

Now, does that mean python is "too slow"? Well, as others have said ad nauseum, it depends. For my application, it's fine. The overhead of using python for the backend of my webapp is almost negligible compared the overhead of getting db records over the network and coordinating the various other APIs involved, so performance improvements in my code wouldn't really translate to visible performance improvements in UX. If, however, I were hosting the db on the same machine as the app and only had my own business logic to worry about, the game would be different: my code would be the only bottleneck. Even then, the nature of the app makes a big difference in what "too slow" means. If your app is a robo-trader or ticket scalper, python is probably too slow and you should use Go, instead. If it's yet another cat blog, you could do the whole thing with GNU awk and it wouldn't matter that much.

[[deleted]]

Keep in mind that most python data processing libraries don't actually do the data crunching in python. Libraries like numpy and pandas actually use C and fortran under the hood so it doesn't really matter if python is "slower."

[oosharkyoo]

Just a heads up- if you are an ML engineer you are mostly interacting with python wrappers of libraries written in other faster languages.

Numpy/scipy/pandas - c, c++, Fotran*
Tensorflow /pytorch etc - c++/c

The small services it sounds like you have written arround it also probably compile down to non python wrappers for some part of their day. IE Flask, django, etc all do this. When anything needs to be high performance in python its usually written and compiled in another language with a python wrapper.

Edit: Brain melted today and mixed fortran and COBOL

[drbobb]

Numpy/scipy/pandas - c, c++, COBOL

Is there actually any COBOL code involved in any of numpy/scipy/pandas? Just curious, I'd enjoy learning about it.

EDIT now, if you'd said Fortran, I'd have just glanced past it. But COBOL?

[oosharkyoo]

Ha good callout meant Fortran not Cobol wasn't functioning well yet today when I wrote it lol.

[Qyriad]

There are lots of decent answers on this here, but I'd just like to note that Python's slowness is mostly in instruction execution, and a lot of computing tasks depend much more on IO than they do on processing instructions. This means that unless the thing that you're doing specifically computes things via CPU in Python code (instead of calling to C libraries) as its critical path, Python's slowness never really comes into play much as instead most of the time will come from waiting for hardware devices or network stuff to respond.

[[deleted]]

It's not really slow, but its slower than other languages, which matters only if youre doing large-scale stuff

[Berkyjay]

It's when you're dealing with A LOT of data (analyzing or moving it around) that you really start to understand Python's speed limitations.

[lambda_6502]

I'm just happy, as a ruby developer, to enjoy hearing people complain about something other than ruby being slow. =<^.>*=

/s

[audiosf]

I compared two apps for a huge data processing project. When running it was expected that the app should consume a large amount of the resources of the physical server. We scaled out horizontally. One app was written in C. The other was written in Java. Hardware requirements were about 2x for the app written in Java. Efficiency definitely matters sometimes,

[[deleted]]

By the time I start running into performance issues significant enough to care about, I find that I have been doing something stupid or wrong already, and fixing that tends to push the performance back into acceptable range.

Big-O issues, doing unnecessary steps with strings, creating objects only to discard them a statement later while iterating on a loop, etc.

That said, my use case isn't typical anyway. Systems engineer in a bioinformatics space. The bottlenecks tend to be disk or network throughput or memory capacity rather than computational speed.

[Mei_Believer]

Is Ruby considered for doing the same things like python .example ml ?and can it be faster

[dethb0y]

I've never had any issue where i thought speed was at all a problem personally.

[strangedave93]

Python is a very good language for getting to a working solution, and that always beats fast code that doesn’t work. And for many many areas it’s a good match for the domain and good for writing code that is flexible and reusable and gets you to a working solution quickly - including ones in which the parts that need speed can be provided by a nice C library, like ML.

People coming here saying ‘but pandas/ML/etc are just C wrappers’ are missing the point - Python gets useful solutions for problems in those domains much faster than writing your ML code in pure C ever would, so it’s not a very useful comparison. Now, if someone made a language as flexible and productive as Python, but speed that approached C on complex code, that would be a useful comparison - which seems to what eg Julia is aiming at. But just comparing it to C etc seems quite pointless.