Thoughts about PyScript Performance #2347
Replies: 2 comments 3 replies
-
that's what Pyodide and MicroPython do: they bring the native interpreter to WASM which "compile" at runtime just like Python does. The claim pyscript is very slow is a bit lame to me:
Most importantly, the plethora of demos out there based on WebGL games to complex data-visualization applications would beg to differ your conclusion but it's true that we know some area could improve, yet it has nothing strictly to do with PyScript:
The WASM target/runtime lacks cooperative GC and JIT but this has nothing to do with PyScript and it's not even Pyodide or MicroPython fault so ... what you are suggesting should rather land at WHATWG as it's a request for browsers/vendors, not for this team, we can't decide what browsers ship out there. As summary, I think we should quickly edit the title of this discussion as it does a bad job at proposing anything concrete or addressable by the PyScript team but I'll wait @ntoll thoughts in case he has a different opinion. |
Beta Was this translation helpful? Give feedback.
-
Hey hey @MominIqbal-1234 - thank you for the feedback and kind words, it's really appreciated. So, performance. 😄 That's a difficult nut to crack. As @WebReflection pointed out, there are lots of complex factors related to the performance of PyScript. It is not enough just to say, "PyScript is very slow"... because I want to reply by asking, "compared to what, and in what dimension of measurement?". 😉 Does it start quickly? That depends on the runtime and (crucially, something over which we don't have control) network latency on first load. Does it evaluate code quickly? The biggest factor is likely the quality of the code PyScript is evaluating - even the world's fastest computer coupled with efficiently compiled code will grind to a halt if the code itself is written to perform as So, as always, the answer to the question of PyScript performance is, "it depends". 👍 My personal view is to ask, "is PyScript's performance, across many different quantitative and qualitative dimensions, good enough?" That these various dimensions interfere with each other means we have to think very carefully about the trade-offs of preferring one type of performance over another. Crucially this means we pay attention in an enlarged and broad minded manner - and NOT just focus on "speed" (again, of what? Startup, execution, interaction with the browser, compilation of bytecode etc..?) These are important discussions to have, and we welcome your comment, but (if I may), I'll change the title from the rather loaded, "PyScript is slow" to "Thoughts about PyScript Performance", since this is less pejorative and more accurately reflects the subtle, nuanced and very Very VERY difficult task of engaging with the performance characteristics of PyScript. 🤔 So, let the discussion begin..! This is what open-source engineering is all about. We lift each other up. 🚀 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Huge Appreciation to the PyScript Team 🙌
Thank you to the entire PyScript team for building such an awesome project! It's a major step forward for Python in the browser.
Why JavaScript Feels So Fast in Browsers ⚡
JavaScript is incredibly fast in the browser, likely because it's compiled by highly optimized JavaScript engines like V8 (used in Chromium). These engines are deeply integrated into the browser itself, which gives JS a big performance advantage.
Can Python Catch Up? 🐍🚀
If we can integrate a Python compiler directly into the browser—similar to how JavaScript is integrated—it could become a real competitor to JavaScript. Collaborating with browser projects like Chromium could make this possible.
Final Thought 💡
With continued innovation and support, PyScript could transform how we build and run Python in the browser, opening up new possibilities for developers worldwide.
Beta Was this translation helpful? Give feedback.
All reactions