10 ms·

Python performance myths and fairy tales

• NeutralForest 1y ago
  Cool article, I think a lot of those issues are not Python specific so it's a good overview of whatever others can learn from a now 30 years old language! I think we'll probably go down the JS/TS route where another compiler (Pypy or mypyc or something else) will work alongside CPython but I don't see Python4 happening.
  • tweakimp 1y ago
    I thought we would never see the GIL go away and yet, here we are. Never say never. Maybe Python4 is Python with another compiler.
    • pjmlp 1y ago
      It required Facebook and Microsoft to change the point of view on it, and now the Microsoft team is no more. So lets see what remains from CPython performance efforts.
  • ngrilly 1y ago
    I’m not sure I understand the reference to JS/TS: TS is only a type checker and has zero effect on runtime performance.
• PontingClarke 1y ago
  [dead]
• 2d8a875f-39a2-4 1y ago
  Do you still need an add-on library to use more than one core?
  • BlackFly 1y ago
    Latest version officially supports full-threaded mode: https://docs.python.org/3.14/whatsnew/3.14.html#whatsnew314-pep779 https://docs.python.org/3.14/whatsnew/3.14.html#whatsnew314-...
  • franktankbank 1y ago
    Eh? Multiprocessing has existed since 2.X days.
• writebetterc 1y ago
  Good job on dispelling the myth of "compiler = fast". I hope SPython will be able to transfer some of its ideas to CPython with time.
  • nromiun 1y ago
    You would think Luajit would have convinced people by now. But most people still think you need a static language and an AOT compiler for performance.
    • pjmlp 1y ago
      Also Smalltalk (Pharo, Squeak, Cincom, Dolphin), Common Lisp (SBCL, Clozure, Allegro, LispWorks), Self,.... But yeah.
  • mrkeen 1y ago
    Where was this dispelled?
• meinersbur 1y ago
  Is it just me or does the talk actually confirm all its Python "myths and fairy tales"?
  • daneel_w 1y ago
    It confirms that Python indeed has poor executional performance.
  • xg15 1y ago
    Well, the fairy tale was that Python was fast, or "fast enough" or "fast if we could compile it and get rid of the GIL".
• quantumspandex 1y ago
  So we are paying 99% of the performance just for the 1% of cases where it's nice to code in. Why do people think it's a good trade-off?
  • nromiun 1y ago
    Because it's nice to code in. Not everything needs to scale or be fast. Personally I think it is more crazy that you would optimize 99% of the time just to need it for 1% of the time.
    • BlackFly 1y ago
      It isn't an either or choice. The people interested in optimizing the performance are typically different people than those interested in implementing syntactic sugar. It is certainly true that growing the overall codebase risks introducing tensions for some feature sets but that is just a consideration you take when diligently adding to the language.
    • nomel 1y ago
      That’s why Python is the second best language for everything. The amount of complexity you can code up in a short time, that most everyone can contribute to, is incredible.
  • dgfitz 1y ago
    I can say with certainty I’ve never paid a penny. Have you?
  • lmm 1y ago
    Because computers are more than 100x faster than they were when I started programming, and they were already fast enough back then? (And meanwhile my coding ability isn't any better, if anything it's worse)
    • dr-detroit 1y ago
      [dead]
• nromiun 1y ago
  I really hope PyPy gets more popular so that I don't have to argue Python is pretty fast for the nth time. Even if you have to stick to CPython, Numba, Pythran etc, can give you amazing performance for minimal code changes.
• btown 1y ago
  I think an important bit of context here is that computers are very, very good at speculative happy-path execution. The examples in the article seem gloomy: how could a JIT possibly do all the checks to make sure the arguments aren’t funky before adding them together, in a way that’s meaningfully better than just running the interpreter? But in practice, a JIT can create code that does these checks, and modern processors will branch-predict the happy path and effectively run it in parallel with the checks. JavaScript, too, has complex prototype chains and common use of boxed objects - but v8 has made common use cases extremely fast. I’m excited for the future of Python.
  • DanielHB 1y ago
    The main problem is when the optimizations silently fail because of seemingly innocent changes and suddenly your performance tanked 10x. This is a problem with any language really (CPU cache misses are a thing afterall and many non-dynamic languages have boxed objects) but it is a much, much worse in dynamic languages like Python, JS and Ruby. Most of the time it doesn't matter, most high-throughput python code just invokes C/C++ where these concerns are not as big of a problem. Most JS code just invokes C/C++ browser DOM objects. As long as the hot-path is not in those languages you are not at such high risk of "innocent change tanked performance" Even server-side most JS/Python/Ruby code is just simple HTTP stack handlers and invoking databases and shuffling data around. And often large part of the process of handling a request (encoding JSON/XML/etc, parsing HTTP messages, etc) can be written in lower-level languages.
  • nxobject 1y ago
    To be slightly flip, we could say that the Lisp Machine CISC-supports-language full stack design philosophy lives on in how massive M-series reorder buffers and ILP supports JavaScriptCore.
  • jerf 1y ago
    That makes it so that in absolute terms, Python is not as slow as you might naively expect. But we don't measure programming language performance in absolute terms. We measure them in relative terms, generally against C. And while your Python code is speculating about how this Python object will be unboxed, where its methods are, how to unbox its parameters, what methods will be called on those, etc., compiled code is speculating on actual code the programmer has written, running that in parallel, such that by the time the Python interpreter is done speculating successfully on how some method call will resolve with actual objects the compiled code language is now done with ~50 lines of code of similar grammatical complexity. (Which is a sloppy term, since this is a bit of a sloppy conversation, but consider a series "p.x = y"-level statements in Python versus C as the case I'm looking at here.) There's no way around it. You can spend your amazingly capable speculative parallel CPU on churning through Python interpretation or you can spend it on doing real work, but you can't do both. After all, the interpreter is just C code too. It's not like it gets access to special speculation opcodes that no other program does.
• mrkeen 1y ago
  I didn't read with 100% focus, but this lwn account of the talk seemed to confirm those myths instead of debunking.
  • diegocg 1y ago
    Yep, for me it confirms all the reasons why I think python is slow and not a good language for anything that goes beyond a script. I work with it everyday, and I have learned that I can't even trust tooling such as mypy because it's full of corner cases - turns out that not having a clear type design in a language is not something that can be fundamentally fixed by external tools. Tests are the only thing that can make me trust code written in this language
    • jdhwosnhw 1y ago
      > Yep, for me it confirms all the reasons why I think python is slow Yes, that is literally the explicit point of the talk. The first myth of the article was “python is not slow“
  • postexitus 1y ago
    A more careful reading of the article is required. The first myth is "Python is not slow" - it is debunked, it is slow. The second myth is ""it's just a glue language / you just need to rewrite the hot parts in C/C++" - it is debunked, just rewriting stuff in C/Rust does not help. The third myth is " Python is slow because it is interpreted" - it is debunked, it is not slow only because it is interpreted.
    • mrkeen 1y ago
      Thanks! As a Python outsider, I was primed for a Python insider to be trying to change my views, not confirm them, and I did indeed misread.
      • zahlman 1y ago
        My impression is that GvR conceded a long time ago that Python is slow, and doesn't particularly care (and considers it trolling to keep bringing it up). The point is that in the real world this doesn't matter a lot of the time, at least as long as you aren't making big-O mistakes — and easier-to-use languages make it easier to avoid those mistakes. For that matter, I recently saw a talk in the Python world that was about convincing people to let their computer do more work locally in general, because computers really are just that fast now.
• pjmlp 1y ago
  Basically, leave Python for OS and application scripting tasks, and as BASIC replacement for those learning to program.
  • aragilar 1y ago
    And yet, most of what people end up doing ends up being effectively OS and application scripting. Most ML projects are really just setting up a pipeline and telling the computer to go and run it. Cloud deployments are "take this yaml and transform it some other yaml". In as much as I don't want to use Fortran to parse a yaml file, I don't really want to write an OS (or a database) in Python. Even something like django is mostly deferring off tasks to faster systems, and is really about being a DSL-as-programming-language while still being able to call out to other things (e.g. ML code).
    • pjmlp 1y ago
      I would rather use Fortran actually, not all of us are stuck with Fortran 77. Ironically Fortran support is one of the reasons CUDA won over OpenCL. Having said that, plenty of programming languages with JIT/AOT toolchains have nice YAML parsers, I don't see the need to bother with Python for that.
• Ulti 1y ago
  Feel like Mojo is worth a shoutout in this context https://www.modular.com/mojo https://www.modular.com/mojo Solves the issue of having a superset of Python in syntax where "fn" instead of "def" functions are assumed static typed and compilable with Numba style optimisations.
  • _aavaa_ 1y ago
    Mojo NOT being open-source is a complete non-starter.
    • alankarmisra 1y ago
      Genuinely curious; while I understand why we would want a language to be open-source (there's plenty of good reasons), do you have anecdotes where the open-sourceness helped you solve a problem?
      • yupyupyups 1y ago
        Not the OP, but I have needed to patch Qt due to bugs that couldn't be easily worked around. I have also been frustrated while trying to interoperate with expensive proprietary software because documentation was lacking, and the source code was unavailable. In one instance, a proprietary software had the source code "exposed", which helped me work around its bugs and use it properly (also poorly documented). There are of course other advantages of having that transparancy, like being able to independently audit the code for vulnerabilities or unacceptable "features", and fix those. Open source is oftentimes a prerequisite for us to be able to control our software.
      • _aavaa_ 1y ago
        It has helped prevent problems. I am not worried about a python suddenly adding a clause stating that I can’t release a ML framework…
      • Philpax 1y ago
        In the earlier days of rustc, it was handy to be able to look at the context for a specific compiler error (this is before the error reporting it is now known for). Using that, I was able to diagnose what was wrong with my code and adjust it accordingly.
• abhijeetpbodas 1y ago
  An earlier version of the talk is at https://www.youtube.com/watch?v=ir5ShHRi5lw https://www.youtube.com/watch?v=ir5ShHRi5lw (I could not find the EuroPython one).
  • fragebogen 1y ago
    Here's a newer one https://www.youtube.com/watch?v=1uFMW0IcZuw https://www.youtube.com/watch?v=1uFMW0IcZuw
• ic_fly2 1y ago
  It’s a good article on speed. But honestly the thing that makes any of my programs slow is network calls. And there a nice async setup goes a long way. And then k8 for the scaling.
  • nicolaslem 1y ago
    This. I maintain an ecommerce platform written in Python. Even with Python being slow, less than 30% of our request time is spent executing code, the rest is talking to stuff over the network.
  • stackskipton 1y ago
    SRE here, that horizontal scaling with Python has impacts as it’s more connections to database and so forth so you are impacting things even if you don’t see it.
    • ic_fly2 1y ago
      Meh, even with basic async I’ve been able to overload azure’s premium ampq offering memory capacity. But yes managing db connections is a pain. But I don’t think it’s any better in Java (my only other reference at this scale)
    • wussboy 1y ago
      That’s why we use Firestore
  • gen220 1y ago
    I think articles like this cast too wide a net when they say "performance" or "<language> is fast/slow". A bunch of SREs discussing which languages/servers/runtimes are fast/slow/efficient in comparable production setups would give more practical guidance. If you're building an http daemon in a traditional three-tiered app (like a large % of people on HN), IME, Python has quietly become a great language in that space, compared to its peers, over the last 8 years.
• ntoll 1y ago
  Antonio is a star. He's also a very talented artist.
• dgan 1y ago
  "Rewrite the hot path in C/C++" is also a landmine because how inefficient the boundary crossing is. so you really need "dispatch as much as possible at once" instead of continuously calling the native code
  • aragilar 1y ago
    Isn't this just a specific example of the general rule of pulling out repeated use of the same operation in a loop? I'm not sure calls out to C are specifically slow in CPython (given many operations are really just calling C underneath).
    • KeplerBoy 1y ago
      The key is to move the entire loop to a compiled language instead of just the inner operation.
    • dgan 1y ago
      they are specifically slow. there was a project which measured FFI cost in different languages, and python is awfully bad
    • Twirrim 1y ago
      The serialisation cost of translating data representations between python and C (or whatever compiled language you're using) is notable. Instead of having the compiled code sit in the centre of a hot loop, it's significantly better to have the loop in the compiled code and call it once https://pythonspeed.com/articles/python-extension-performance/ https://pythonspeed.com/articles/python-extension-performanc...
      • morkalork 1y ago
        The overhead of copying and moving data around in Python is frustrating. When you are CPU bound on a task, you can't use threads (which do have shared memory) because of the GIL, so you end up using whole processes and then waste a bunch of cycles communicating stuff back and forth. And yes, you can create shared memory buffers between Python processes but that is nowhere near as smooth as say two Java threads working off a shared data structure that's got synchronized sprinkled on it.
• robmccoll 1y ago
  Python as a language will likely never have a "fast" implementation and still be Python. It is way too dynamic to be predictable from the code alone or even an execution stream in a way that allows you to simplify the actual code that will be executed at runtime either through AOC or JIT. The language is itself is also quite large in terms of syntax and built-in capability at this point which makes new feature-conplete implementations that don't make major trade offs quite challenging. Given how capable LLMs are at translating code, it seems like the perfect time to build a language with similar syntax, but better scoped behavior, stricter rules around typing, and tooling to make porting code and libraries automated and relatively painless. What would existing candidates be and why won't they work as a replacement?
  • acmj 1y ago
    Pypy is 10x faster and is compatible with most cpython code. IMHO it was a big mistake not to adopt JIT during the 2-to-3 transition.
    • cestith 1y ago
      That “most” is doing a big lift there. At some point you might consider that you’re actually programming in the language of Pypy and not pure Python. It’s effectively a dialect of the language like Turbo Pascal vs ISO Pascal or RPerl instead of Perl.
      • cma 1y ago
        Most is more CPython code than python 3 was compatible with. But the port of the broken code was likely much easier than if it had moved to a JIT at the same time too.
    • rirze 1y ago
      Isn't there an incoming JIT in 3.14?
  • pjmlp 1y ago
    Self and Smalltalk enter the room. As for the language with similar syntax, do you want Nim, Mojo or Scala 3?
• nu11ptr 1y ago
  The primary focus here is good and something I hadn't considered: python memory being so dynamic leads to poor cache locality. Makes sense. I will leave that to others to dig into. That aside, I was expecting some level of a pedantic argument, and wasn't disappointed by this one: "A compiler for C/C++/Rust could turn that kind of expression into three operations: load the value of x, multiply it by two, and then store the result. In Python, however, there is a long list of operations that have to be performed, starting with finding the type of p, calling its __getattribute__() method, through unboxing p.x and 2, to finally boxing the result, which requires memory allocation. None of that is dependent on whether Python is interpreted or not, those steps are required based on the language semantics." The problem with this argument is the user isn't trying to do these things, they are trying to do multiplication, so the fact that the lang. has to do all things things in the end DOES mean it is slow. Why? Because if these things weren't done, the end result could still be achieved. They are pure overhead, for no value in this situation. Iow, if Python had a sufficiently intelligent compiler/JIT, these things could be optimized away (in this use case, but certainly not all). The argument is akin to: "Python isn't slow, it is just doing a lot of work". That might be true, but you can't leave it there. You have to ask if this work has value, and in this case, it does not. By the same argument, someone could say that any interpreted language that is highly optimized is "fast" because the interpreter itself is optimized. But again, this is the wrong way to think about this. You always have to start by asking "What is the user trying to do? And (in comparison to what is considered a fast language) is it fast to compute?". If the answer is "no", then the language isn't fast, even if it meets the expected objectives. Playing games with things like this is why users get confused on "fast" vs "slow" languages. Slow isn't inherently "bad", but call a spade a spade. In this case, I would say the proper way to talk about this is to say: "It has a fast interpreter". The last word tells any developer with sufficient experience what they need to know (since they understand statically compiled/JIT and interpreted languages are in different speed classes and shouldn't be directly compared for execution speed).
  • andylei 1y ago
    The previous paragraph is > Another "myth" is that Python is slow because it is interpreted; again, there is some truth to that, but interpretation is only a small part of what makes Python slow. He concedes its slow, he's just saying it's not related to how interpreted it is.
• teo_zero 1y ago
  I don't know Python so well as to propose any meaningful contribution, but it seems to me that most issues would be mitigated by a sort of "final" statement or qualifier, that prohibits any further changes to the underlying data structure, thus enabling all the nice optimizations, tricks and shortcuts that compilers and interpreters can't afford when data is allowed to change shape under their feet.
  • Fraterkes 1y ago
    I assume people dislike those kinds of solutions because the extreme dynamism is used pretty rarely in a lot of meat and potatoes python scripst. So a lot of “regular” python scripts would have to just plaster “final” everywhere to make it as fast as it can be. At that point youd maybe want to have some sort of broader way to signify which parts of your script are dynamic. But then, youd have a language that can be dynamic even in how dynamic it is…
• game_the0ry 1y ago
  I know I am going to get some hate for this from the "Python-stans" but..."python" and "performance" should never be associated with each other, and same for any scripting/interpreted programming language. Especially if it has a global interpreter lock. While performance (however you may mean that) is always a worthy goal, you may need to question your choice of language if you start hitting performance ceilings. As the saying goes - "Use the right tool for the job." Use case should dictate tech choices, with few exceptions. Ok, now that I have said my piece, now you can down vote me :)
  • danielrico 1y ago
    That's used by some people as excuse to write the most inefficient code. Ok, you are not competing with c++, but also you shouldn't be redoing all the calculations because you haven't figured the data access pattern..
  • ahoka 1y ago
    Have you read the fine article?
    • game_the0ry 1y ago
      I did, thought it was pretty good an upvoted it.
  • throwaway6041 1y ago
    > the "Python-stans" I think the term "Pythonistas" is more widely used > you may need to question your choice of language if you start hitting performance ceilings. Developers should also question if a "fast" language like Rust is really needed, if implementing a feature takes longer than it would in Python. I don't like bloat in general, but sometimes it can be worth spinning up a few extra instances to get to market faster. If Python lets you implement a feature a month earlier, the new sales may even cover the additional infrastructure costs. Once you reach a certain scale you may need to rewrite parts of your system anyway, because the assumptions you made are often wrong.
    • 1y ago
• crabbone 1y ago
  Again and again, the most important question is "why?" not "how?". Python isn't made to be fast. If you wanted a language that can go fast, you needed to build it into the language from the start: give developers tools to manage memory layout, give developers tools to manage execution flow, hint the compiler about situations that present potential for optimization, restrict dispatch and polymorphism, restrict semantics to fewer interpretations. Python has none of that. It's a hyper-bloated language with extremely poor design choices all around. Many ways of doing the same thing, many ways of doing stupid things, no way of communicating programmer's intention to the compiler... So why even bother? Why not use a language that's designed by a sensible designer for this specific purpose? The news about performance improvements in Python just sound to me like spending useful resources on useless goals. We aren't going forward by making Python slightly faster and slightly more bloated, we just make this bad language even harder to get rid of.
  • Danmctree 1y ago
    The frustrating thing is that the math and AI support in the python ecosystem is arguably the best. These happen to also be topics where performance is critical and where you want things to be tight. c++ has great support too but often isn't usable in communities involving researchers and juniors because it's too hard for them. Startup costs are also much higher. Ans so you're often stuck with python. We desperately need good math/AI support in faster languages than python but which are easier than c++. c#? Java?
    • pjmlp 1y ago
      It is kind of ironic that this is now the Zeitgeist, while in the 1990's my university used to teach C++ to first year students, and I learned it as high school student with Turbo C++ 1.0 for MS-DOS, about a year after it was made commercially available, later acquiring Turbo C++ 1.5 for Windows 3.1 with student discount.
• adsharma 1y ago
  The most interesting part of this article is the link to SPy. Attempts to find a subset of python that could be made performant.
  • ajross 1y ago
    Honestly that seems Sisyphean to me. The market doesn't want a "performant subset". The market is very well served by performant languages. The market wants Python's expressivity. The market wants duck typing and runtime-inspectable type hierarchies and mutable syntax and decorators. It loves it. It's why Python is successful. My feeling is that numba has exactly the right tactic here. Don't try to subset python from on high, give developers the tools[1] so that they can limit themselves to the fast subset, for the code they actually want. And let them make the call. (The one thing numba completely fails on though is that it insists on using its own 150+MB build of LLVM, so it's not nearly as cleanly deployable as you'd hope. Come on folks, if you use the system libc you should be prepared to use the system toolchain.) [1] Simple ones, even. I mean, to first approximation you just put "@jit" on the stuff you want fast and make sure it sticks to a single numeric type and numpy arrays instead of python data structures, and you're done.
    • zozbot234 1y ago
      > The market wants duck typing and runtime-inspectable type hierarchies and mutable syntax and decorators. It loves it. These features have one thing in common: they're only useful for prototype-quality throwaway code, if at all. Once your needs shift to an increased focus on production use and maintainability, they become serious warts. It's not just about performance (though it's obviously a factor too), there's real reasons why most languages don't do this.
      • ajross 1y ago
        > These features have one thing in common: they're only useful for prototype-quality throwaway code, if at all. As a matter of practice: the python community disagrees strongly. And the python community ate the world. It's fine to have an opinion, but you're not going to change python.
• pabe 1y ago
  The SPy demo is really good in showing the the difference in performance between Python and their derivative. Well done!
• hansvm 1y ago
  In the "dynamic" section, it's much worse than the author outlines. You can't even assume that the constant named "10" will point to a value which behaves like you expect the number 10 to behave.
  • zahlman 1y ago
    I guess you mean "N". 10 is a literal, not a name. The part "N cannot be assumed to be ten, because that could be changed elsewhere in the code" implies well enough that the change could be to a non-integer value. (For that matter, writing `N: int = 10` does nothing to fix that.)
    • hansvm 1y ago
      No, I mean the literal. CPython is more flexible than it has any right to be, and you're free to edit the memory pointed to by the literal 10.
      • zahlman 1y ago
        Care to show how you believe this can be achieved, from within Python?
        • hansvm 1y ago
          import ctypes ten = 10 addr = id(ten) class PyLongObject(ctypes.Structure): _fields_ = [ ("ob_refcnt", ctypes.c_ssize_t), ("ob_type", ctypes.c_void_p), ("ob_size", ctypes.c_ssize_t), ("ob_digit", ctypes.c_uint32 * 1), ] long_obj = PyLongObject.from_address(addr) long_obj.ob_digit[0] = 3 assert 10 == 3 # using an auxiliary variable to prevent any inlining # done at the interpreter level before actually querying # the value of the literal `10` x = 3 assert 10 * x == 9 assert 10 + x == 6
          • zahlman 1y ago
            Okay, but this is going out of one's way to view the runtime itself as a C program and connect to it with the FFI. For that matter, the notion that the result of `id` (https://docs.python.org/3/library/functions.html#id https://docs.python.org/3/library/functions.html#id) could sensibly be passed to `from_address` is an implementation detail. This is one reason the language suffers from not having a formal specification: it's unclear exactly how much of this madness alternative implementations like PyPy are expected to validate against. But I think people would agree that poking at the runtime's own memory cannot be expected to give deterministic results, and thus the implementation should in fact consider itself free to assume that isn't happening. (After all, we could take that further; e.g. what if we had another process do the dirty work?)
• pu_pe 1y ago
  Python and other high-level languages may actually decrease in popularity with better LLMs. If you are not the one programming it, might as well do it in a more performant language from the start.
  • richard_todd 1y ago
    In my workflows I already tend to tell LLMs to write scripts in Go instead of python. The LLM doesn't care about the increased tediousness and verbosity that would drive me to Python, and the result will be much faster.
    • Philpax 1y ago
      I saw a short post to this effect here: https://solmaz.io/typed-languages-are-better-suited-for-vibecoding https://solmaz.io/typed-languages-are-better-suited-for-vibe...
  • pjmlp 1y ago
    LLMs will make most languages irrelevant indeed, just like most developers have no idea about the Assembly/machine code that the JIT/AOT compilers of their favourite programming language happen to generate. Eventually LLMs might even generate executables directly.
• fumeux_fume 1y ago
  Slow or fast ultimately matter in the context for which you need to use it. Perhaps these are only myths and fairly tales for an incredibly small subset of people who value execution speed as the highest priority, but choose to use Python for implementation.
• Mithriil 1y ago
  > His "sad truth" conclusion is that "Python cannot be super-fast" without breaking compatibility. A decent case of Python 4.0? > So, maybe, "a JIT compiler can solve all of your problems"; they can go a long way toward making Python, or any dynamic language, faster, Cuni said. But that leads to "a more subtle problem". He put up a slide with a trilemma triangle: a dynamic language, speed, or a simple implementation. You can have two of those, but not all three. This trilemma keeps getting me back towards Julia. It's less simple than Python, but much faster (mitigated by pre-compilation time), and almost as dynamic. I'm glad this language didn't die.
  • Alex3917 1y ago
    > A decent case of Python 4.0? I definitely agree with this eventually, but for now why not just let developers set `dynamic=False` on objects and make it opt in? This is how Google handles breaking Angular upgrades, and in practice it works great because people have multiple years to prepare for any breaking changes.
  • zahlman 1y ago
    > A decent case of Python 4.0? I think "Python 4.0" is going to have to be effectively a new language by a different team that simply happens to bear strong syntactic similarities. (And at least part of why that isn't already happening is that everyone keeps getting scared off by the scale of the task.) Thanks for the reminder that I never got around to checking out Julia.
    • olejorgenb 1y ago
      Isn't that kinda what Mojo is?
      • wraptile 1y ago
        closed sourced proprietary language will never be able to succeed Python here.
      • zahlman 1y ago
        I haven't tried it, but that matches my understanding, yeah. Personally I'd be more interested in designing from scratch.
• taeric 1y ago
  Is amusing to see the top comment on the site be about how Common LISP approached this. And hard not to agree with it. I don't understand how we had super dynamic systems decades ago that were easier to optimize than people care to understand. Heaven help folks if they ever get a chance to use Mathematica.
• tuna74 1y ago
  In computing terms, saying something is "slow" is kind of pointless. Saying something is "effective" or "low latency" provides much more information.
• Redoubts 1y ago
  Wonder if mojo has gotten anywhere further, since they’re trying to bring speed while not sacrificing most of the syntax https://docs.modular.com/mojo/why-mojo/#a-member-of-the-python-family https://docs.modular.com/mojo/why-mojo/#a-member-of-the-pyth...
• actinium226 1y ago
  A lot of the examples he gives, like the numpy/calc function, are easily converted to C/C++/Rust. The article sort of dismisses this at the start, and that's fine if we want to focus on the speed of Python itself, but it seems like both the only solution and the obvious solution to many of the problems specified.
• lkirk 1y ago
  For me, in my use of Python as a data analysis language, it's not python's speed that is an annoyance or pain point, it's the concurrency story. Julia's built in concurrency primatives are much more ergonomic in my opinion.
• 1vuio0pswjnm7 1y ago
  "He started by asking the audience to raise their hands if they thought "Python is slow or not fast enough";" Wrong question Maybe something like, "Python startup time is as fast as other interpreters" Comparatively, Python (startup time) is slow(er)
• ehsantn 1y ago
  The article highlights important challenges regarding Python performance optimization, particularly due to its highly dynamic nature. However, a practical solution involves viewing Python fundamentally as a Domain Specific Language (DSL) framework, rather than purely as a general-purpose interpreted language. DSLs can effectively be compiled into highly efficient machine code. Examples such as Numba JIT for numerical computation, Bodo JIT/dataframes for data processing, and PyTorch for deep learning demonstrate this clearly. Python’s flexible syntax enables creating complex objects and their operators such as array and dataframe operations, which these compilers efficiently transform into code approaching C++-level performance. DSL operator implementations can also leverage lower-level languages such as C++ or Rust when necessary. Another important aspect not addressed in the article is parallelism, which DSL compilers typically handle quite effectively. Given that data science and AI are major use cases for Python, compilers like Numba, Bodo, and PyTorch illustrate how many performance-critical scenarios can already be effectively addressed. Investing further in DSL compilers presents a practical pathway to enhancing Python’s performance and scalability across numerous domains, without compromising developer usability and productivity. Disclaimer: I have previously worked on Numba and Bodo JIT.
  • echoangle 1y ago
    Was this comment written by an LLM?
• coldtea 1y ago
  One big Python performance myth is the promise made several years ago that Python will get 5x faster in the next 5 years. So far the related changes have brought not even 2x gains.
• johnisgood 1y ago
  > Python is fast enough for some tasks, he said, which is why there are so many people using it and attending conferences like EuroPython. The conclusion is logically flawed: it conflates language popularity with performance, and conference attendance and widespread use are sociological indicators, not evidence of Python's performance. Conflating the two is intellectually negligent. Additionally, Python's speed is largely due to C extensions handling performance-critical tasks, not the interpreter itself. Perl, however, is often faster even in pure code, especially for text processing and regex, thanks to its optimized engine, making it inherently quicker in many common scenarios.
  • thunderfork 1y ago
    [dead]
• zazazx 1y ago
  Whoever wrote that up would be smart to put down the computer language books for a while and brush up on their English composition skills. (Your downvotes prove me right.)
• amai 1y ago
  tldr; link to static python : https://github.com/spylang/spy https://github.com/spylang/spy