Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!news.szaf.org!weretis.net!feeder8.news.weretis.net!reader5.news.weretis.net!news.solani.org!.POSTED!not-for-mail
From: Mild Shock <janburse@fastmail.fm>
Newsgroups: comp.lang.python
Subject: async I/O via threads is extremly slow (Was: Does Python Need Virtual
 Threads?)
Date: Mon, 23 Jun 2025 13:29:09 +0200
Message-ID: <103bdq4$15ut7$1@solani.org>
References: <102isqb$3v5j0$2@dont-email.me> <102kp89$q8c6$1@solani.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 23 Jun 2025 11:29:08 -0000 (UTC)
Injection-Info: solani.org;
	logging-data="1244071"; mail-complaints-to="abuse@news.solani.org"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101
 Firefox/128.0 SeaMonkey/2.53.21
Cancel-Lock: sha1:YQNzIhgwPZAx7bZbOwa5mr4sMAA=
X-User-ID: eJwFwYEBwCAIA7CXZLSA50gn/59gQg8LJYIBDqfHqK4DZv2BwqcWj3PyRt72Ym1uKaNXEei1i9dFszOYB1TOFU8=
In-Reply-To: <102kp89$q8c6$1@solani.org>

Hi,

async I/O in Python is extremly disappointing
and an annoying bottleneck.

The problem is async I/O via threads is currently
extremly slow. I use a custom async I/O file property
predicate. It doesn't need to be async for file

system access. But by some historical circumstances
I made it async since the same file property routine
might also do a http HEAD request. But what I was

testing and comparing was a simple file system access
inside a wrapped thread, that is async awaited.
Such a thread is called for a couple of directory

entries to check a directory tree whether updates
are need. Here some measurement doing this simple
involving some little async I/O:

node.js: 10 ms (usual Promises and stuff)
JDK 24: 50 ms (using Threads, not yet VirtualThreads)
pypy: 2000 ms

So currently PyPy is 200x times slower than node.js
when it comes to async I/O. No files were read or
written in the test case, only "mtime" was read,

via this Python line:

stats = await asyncio.to_thread(os.stat, url)

Bye

Mild Shock schrieb:
> 
> Concerning virtual threads the only problem
> with Java I have is, that JDK 17 doesn't have them.
> And some linux distributions are stuck with JDK 17.
> 
> Otherwise its not an idea that belongs solely
> to Java, I think golang pioniered them with their
> goroutines. I am planning to use them more heavily
> 
> when they become more widely available, and I don't
> see any principle objection that Python wouldn't
> have them as well. It would make async I/O based
> 
> on async waithing for a thread maybe more lightweight.
> But this would be only important if you have a high
> number of tasks.
> 
> Lawrence D'Oliveiro schrieb:
>> Short answer: no.
>>
>> <https://discuss.python.org/t/add-virtual-threads-to-python/91403>
>>
>> Firstly, anybody appealing to Java as an example of how to design a
>> programming language should immediately be sending your bullshit detector
>> into the yellow zone.
>>
>> Secondly, the link to a critique of JavaScript that dates from 2015, from
>> before the language acquired its async/await constructs, should be 
>> another
>> warning sign.
>>
>> Looking at that Java spec, a “virtual thread” is just another name for
>> “stackful coroutine”. Because that’s what you get when you take away
>> implicit thread preemption and substitute explicit preemption instead.
>>
>> The continuation concept is useful in its own right. Why not concentrate
>> on implementing that as a new primitive instead?
>>
>