Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Overhead of Python asyncio tasks

textual.textualize.io

Post reply on HN
Print view View original

51–60 of 88 posts

Re: Overhead of Python asyncio tasks

#51

Post by vishvananda »

vishvananda wrote: post #46
traverseda wrote: post #20

Earlier quoted context omitted.

Python is a really good scripting language? I guess the big alternatives would be C and BASH and I'd pick python for short utilities over both of those any day. How slow do you think python is?

Python is extremely slow for some tasks. I was surprised to discover how slow when I ran some benchmarks, despite having used python for many years at the time. It has been improving lately, but here is a blog post I made on the topic quite a few years ago that has some interesting comparisons: https://gist.github.com/vishvananda/7a2f1942d0e9ffff4093

Just reran the benchmarks from 10 years ago, python is only 37X slower than C on the benchmark now, and the go version is running faster than the C version. Python still has big productivity wins of course...

Re: Overhead of Python asyncio tasks

#52

Post by schmichael »

TickleSteve wrote: post #32
schmichael wrote: post #29

Earlier quoted context omitted.

Your method of estimating instructions includes printing multiple lines which context switch to the kernel to perform IO. I'm not sure how an "instruction count" metric is useful anyway. edit: I'm not actually sure you are counting the context switch, but I still don't think estimating instruction count that way is particularly useful.

Its useful to show how much waste there is in a solution. Having an operation that can be executing 250,000 times per second on a modern processor is extremely slow ... not fast.

250k/s is roughly the same speed as context switching, so while slow for pure computation, it is a reasonable amount of "waste" for switching between concurrent tasks.

If you didn't prevent preemptive context switches during your benchmarking, it's entirely possible the only thing you measured was the context switch time.

This is a fun experiment, but to get a rigorous idea of the overhead involved takes more work than what anyone in the post or comments has done.

Re: Overhead of Python asyncio tasks

#53

Post by simonw »

t3pfaff wrote: post #44
traverseda wrote: post #20

Earlier quoted context omitted.

Python is a really good scripting language? I guess the big alternatives would be C and BASH and I'd pick python for short utilities over both of those any day. How slow do you think python is?

I agree that it is a good scripting language. That's where it excells. A GUI terminal emulator however, is not a script... Python once compiled and using it's underlying c libraries is fast enough by modern standards but it is slow to start and projects using it are prone towards difficult to read/messy code. Obviously the latter is up to the developer(s) and whatever standards they set for themselves but any softwar…

I think you're misunderstanding what Textual is. It's not a GUI terminal emulator: it's a library for building interactive terminal applications.

Re: Overhead of Python asyncio tasks

#54

Post by morelisp »

philote wrote: post #35
jstx1 wrote: post #21

Async Python is still confusing af - when do I need it, what happens under the hood, does it actually help with performance, sometimes the GIL comes into play and sometimes it doesn't, why do we ever use threads at all if there's a GIL, why is it called async io if we can use it for anything. My mind is kind of scattered and people seems to be using a lot of async Python for some reason. Any good resources to clear t…

It's great for when you can do concurrent I/O tasks. For example running a web backend, web scraping, or many API calls. FastAPI (and Starlette that it's built off of) is an async web framework and in my experience performs well. Basically, your program will normally halt when doing I/O, and won't proceed until that I/O is done. During that halt, your program is doing nothing (no cpu being used). With asyncio, you ca…

> the GIL does not come into play at all with async.

In the sense that the GIL is still held and you can have at most one path of Python code executing at a time regardless of whether you use async or threads, sure. Most blocking I/O was already releasing the GIL so the difference is purely in how you can design your modules; for any reasoning about performance the GIL behaves the same way whether you use asyncio or not.

Re: Overhead of Python asyncio tasks

#55

Post by t3pfaff »

mixmastamyk wrote: post #47
t3pfaff wrote: post #44

Earlier quoted context omitted.

I agree that it is a good scripting language. That's where it excells. A GUI terminal emulator however, is not a script... Python once compiled and using it's underlying c libraries is fast enough by modern standards but it is slow to start and projects using it are prone towards difficult to read/messy code. Obviously the latter is up to the developer(s) and whatever standards they set for themselves but any softwar…

You seem to be off by an order or three of magnitude about what is "fast enough" for terminal apps, which haven't been a performance bottleneck for decades. 200k ops per second not fast enough for you? How many words per second do you type? So why wouldn't you use it? I've have since the late 90s and even then it was faster than I could keep up with. Unoptimized Java Swing on SGI was the only thing that wasn't, from…

I really don't know why you are so focused on the speed. Obviously python merely acting as translation to optimized c libraries is going to be fast enough. I said the performance difference was negligible on modern hardware. Python's speed is far from its largest problem as I outlined in the above comment.

Re: Overhead of Python asyncio tasks

#56

Post by t3pfaff »

simonw wrote: post #53
t3pfaff wrote: post #44

Earlier quoted context omitted.

I agree that it is a good scripting language. That's where it excells. A GUI terminal emulator however, is not a script... Python once compiled and using it's underlying c libraries is fast enough by modern standards but it is slow to start and projects using it are prone towards difficult to read/messy code. Obviously the latter is up to the developer(s) and whatever standards they set for themselves but any softwar…

I think you're misunderstanding what Textual is. It's not a GUI terminal emulator: it's a library for building interactive terminal applications.

Yeah I realized that later.

Re: Overhead of Python asyncio tasks

#57

Post by morelisp »

schmichael wrote: post #52
TickleSteve wrote: post #32

Earlier quoted context omitted.

Its useful to show how much waste there is in a solution. Having an operation that can be executing 250,000 times per second on a modern processor is extremely slow ... not fast.

250k/s is roughly the same speed as context switching, so while slow for pure computation, it is a reasonable amount of "waste" for switching between concurrent tasks. If you didn't prevent preemptive context switches during your benchmarking, it's entirely possible the only thing you measured was the context switch time. This is a fun experiment, but to get a rigorous idea of the overhead involved takes more work th…

Matching the cost of a genuine context switch should be a (laughably bad) upper bound for any language's particular concurrency offerings. It is not reasonable.

Re: Overhead of Python asyncio tasks

#58

Post by schmichael »

morelisp wrote: post #57
schmichael wrote: post #52

Earlier quoted context omitted.

250k/s is roughly the same speed as context switching, so while slow for pure computation, it is a reasonable amount of "waste" for switching between concurrent tasks. If you didn't prevent preemptive context switches during your benchmarking, it's entirely possible the only thing you measured was the context switch time. This is a fun experiment, but to get a rigorous idea of the overhead involved takes more work th…

Matching the cost of a genuine context switch should be a (laughably bad) upper bound for any language's particular concurrency offerings. It is not reasonable.

> It is not reasonable.

Reasonableness is relative and use case dependent. The post itself illustrates how the cost is insignificant compared to other "wasteful" operations related to CSS handling.

If this is too much overhead for your use case, there are plenty of other approaches and languages to choose from.

Re: Overhead of Python asyncio tasks

#59

Post by mixmastamyk »

t3pfaff wrote: post #55
mixmastamyk wrote: post #47

Earlier quoted context omitted.

You seem to be off by an order or three of magnitude about what is "fast enough" for terminal apps, which haven't been a performance bottleneck for decades. 200k ops per second not fast enough for you? How many words per second do you type? So why wouldn't you use it? I've have since the late 90s and even then it was faster than I could keep up with. Unoptimized Java Swing on SGI was the only thing that wasn't, from…

I really don't know why you are so focused on the speed. Obviously python merely acting as translation to optimized c libraries is going to be fast enough. I said the performance difference was negligible on modern hardware. Python's speed is far from its largest problem as I outlined in the above comment.

I see, thought it was the main point, but there were others...

> but it is slow to start

This is not really true either. Sure not as fast as C, but imperceptible for the most part. And they have improved it in recent versions.

Yes, you can cause it be an issue with a poorly written or though out system, this happened at one job I had. But that wasn't Python's fault they decided to pull in thousands of files each invocation.

My Python scripts respond instantly, even big ones. I have a CLI photo editor and implementation lang is not an issue that I even contemplated until now.

> and projects using it are prone towards difficult to read/messy code.

Primarily large ones with a long history of alternating developers. There are great tools to improve its scalability; use them. The simple pyflakes will eliminate most issues. Type checking gets the long tail for the mission-important+.

Re: Overhead of Python asyncio tasks

#60

Post by seanw444 »

brrrrrm wrote: post #42

JavaScript is 10-37x faster out of the box without any imports async function time_tasks(count=100) { async function nop_task() { return performance.now(); } const start = performance.now() let tasks = Array(count).map(nop_task) await Promise.all(tasks) const elapsed = performance.now() - start return elapsed / 1e3 } for (let count = 100000; count Outputs (Python 3.11, Bun 0.5.1): % bun textual.ts 100000: 3767797.000…

Bun* is that much faster. Wonder what Node or Deno perform like.
Post reply on HN