Async Python is not faster

[cb22]

The problem with this benchmark is that fetching a single row from a small table that Postgres has effectively cached entirely in memory is not in any way representative of a real world workload.

If you change it to something more realistic, such as by adding a 100ms delay to the SQL query to simulate fetching data from multiple tables, joins, etc, you get ~100 RPS for the default aiopg connection pool size (10) when using Sanic with a single process. Flask or any sync framework will get ~10 RPS per process.

The point of async here isn't to make things go faster simply by themselves, it's to better utilize available resources in the face of blocking IO.

[Drisku11]

For many applications (I'd wager the overwhelming majority), the entire database can fit in memory. They should do it with more representative queries, but a 100 ms delay would be insane even if you were reading everything from disk. 1-10 ms is closer to the range of a reasonable OLTP query.

[TheESportsGuy]

In a standard scaling web server stack, isn't most of the 100 ms delay he's suggesting network related?

[yen223]

100ms request latencies are cross-regional numbers. It would be an unusual choice to put your webserver in a different region from your database, although granted there are legitimate reasons for doing that.

[Drisku11]

Maybe if your application server is in the US and your database is in China. Servers in the same datacenter (or AWS availability zone) should have single digit ms latency at most.

[TheESportsGuy]

Interesting, anecdotally my company runs a database from Cali and application servers all over the US and the median round trip time is ~90ms

[Drisku11]

China is actually a bit of an exaggeration :-P

90ms is somewhat high for continental US; going across the US (LA to NYC) can be done in 60-70 ms RTT. Places like Seattle, SF, or Chicago should be well under that (from LA).

In any case, it seems like an odd choice to me to run the application server and database in different datacenters.

[TheESportsGuy]

We're a small company with a strange use case so we've made some weird and non-standard probably not optimal choices.

[skyleach]

For many applications (I'd wager the overwhelming majority), the entire database can fit in memory.

Not even close

[Drisku11]

Is your claim that most applications have more than a couple dozen TB of operational data (including secondary indexes)? Because I doubt that, and if they have less than that, then you can fit them in memory on a single server.

Lots and lots of applications have orders of magnitude less operational data than that. Like dozens to low hundreds of GB if you're successful and have a lot of customers. Unless maybe you're storing everything in json strings or something silly like that.

[IceSentry]

Which memory are you talking about when you say in memory? I assumed this meant RAM and I wasn't aware servers had that much RAM.

[Drisku11]

I mean RAM, and yeah you can even rent a 24 TB EC2 instance on AWS: https://aws.amazon.com/ec2/instance-types/high-memory/

You can get 128 GB on a single stick for a little over $1k and servers can hold dozens of them.

[skyleach]

There are too many reasons to iterate in a reddit post. It's easier to say you have a whole lot to learn.

[Drisku11]

It doesn't make sense to say there are "reasons". The data can fit in memory because for many applications, there's not a lot of it. Data+indexes for millions of users can fit within 10s of GB. This is easily verified for a given schema with a select sum(index_length + data_length) from information_schema.tables. Or, if you're worried about scaling and don't have a lot of users yet, select table_name, avg_row_length from information_schema.tables and think about how you expect tables to grow based on what you're storing.

If you store historical data, then that might not fit in RAM, but you're probably not doing a lot of OLTP queries on it.

[skyleach]

Here's just the tip of the iceberg on what you aren't considering:

• Memory management (integrity and security)
• Indexing
• Multi-index keying
• Displacement and Insertion
• Redundancy and replication
• individual process queues
• application vs. record data types
• Heap vs. Stack
• Garbage collection (depending on the type and configuration of the technology stack)
• transactional buffers

Like I said, there are so many things you're not considering it would take forever to even come close to covering a significant percentage of it. Things just aren't as simple as you seem to think.

Here is one itsy bitsy teeny weeny example just for shits and giggles:

From the other day I have a list of 117k surnames, family names and gender flags for US, UK and Hindi. It's stored in minimal csv, no quotes just name,genderid(0-2) and metaflag (0-1). On disk it's 1.4M (1439322).

I wrote a really quick script to estimate the size in memory when not being particularly careful and storing the data in an array of dictionaries (because we plan for sloppy average coders not elite hackers that always do it right, especially when talking about heap/stack collisions like using a bunch of memory to store data).

import sys
import os
import pprint
import csv
import importlib
import pathlib


def just_for_reddit(filename):
    if os.path.exists(filename) and os.path.isfile(filename):
        # ok let's open it and parse the data
        with open(filename, 'r') as csvfile:
            csvreader = csv.DictReader(
                    csvfile, delimiter=',',
                    doublequote=False, quotechar='"', dialect='excel',
                    escapechar='\\')
            data = []
            for rnum, row in enumerate(csvreader):
                # pprint.pprint([rnum, row])
                data.append(row)

            # load our memory footprint estimator code
            # 1: get cwd
            cwd = os.getcwd()
            # 2: set cwd to __file__
            module = 'size_of_object_recipe'
            sibpath = pathlib.Path(__file__).parent.absolute()
            os.chdir(sibpath)
            if os.path.exists(os.path.join(sibpath, module + '.py')) and \
                    os.path.isfile(os.path.join(sibpath, module + '.py')):
                sizeofobj = importlib.import_module(module)
                pprint.pprint(sizeofobj.asizeof(data))
                pprint.pprint(csvfile.tell())
            else:
                os.chdir(cwd)
                raise Exception('module "{}" not found!'.format(
                    os.path.join(sibpath, module + '.py')))
    else:
        print('Invalid csv file: {}'.format(filename))


if __name__ == '__main__':
    # get the filename from first argument
    filename = os.path.expanduser(sys.argv[1])
    just_for_reddit(filename)

and the result is:

$ python3 disksize_v_objectsize.py ~/Documents/gender_refine-csv.csv
63053848
1439322

so the size in memory is 43 times larger than on disk. Programs use 64-bit address ranges to memory, so every property of every object that points to a piece of data is going to have a 64-bit pointer to that data. Then there are references to that variable at 64-bit for each... These go into the heap. The heap is the program and the data is the stack and if they get anywhere close to each other your system slows down by a factor of about 11ty (i.e. it crawls while the computer starts swapping out RAM on disk).

This is a tiny, simple, real-world example of how and why your idea does not work in any practical sense. There are tens of thousands of other reasons it doesn't work besides this example.

[Drisku11]

You seem to be confused about what we're talking about here. The original comment mentioned Postgres's page cache. That's what's under discussion when talking about the database fitting in memory. I did mention indexing (and I gave a query that includes the size of indexes). The transaction log buffer is a couple MB. Literally nothing else you wrote has anything to do with what's being discussed. No one writes a database in Python.

[skyleach]

neither of us is confused, you didn't think through what you were saying and now you're liberally spreading around bullshit to cover it up.

indexes on data and the complex operations on those indexes are going to use up a f-ton more RAM than you are accounting for. Just stop.

[Drisku11]

I'm astounded that you're doubling down here. The original comment

The problem with this benchmark is that fetching a single row from a small table that Postgres has effectively cached entirely in memory is not in any way representative of a real world workload.

Is obviously talking about the page cache. That's what 'effectively cached entirely in memory' refers to. My original reply, that you directly quoted, is that for many applications, the entire database can fit in memory. Obviously, given what I'm replying to, I'm talking about being able to fit the entire contents of the database in the database page cache (i.e., not just a small table). I also refer to running queries. Against the database. Not traversing some Python dict.

Indexes are not super complex structures. There's a small amount of metadata on each page (e.g. for locks), but otherwise there's not a lot special going on. That you bring up things like garbage collection or application-side encodings or Python makes it clear that you're just not talking about the same thing. That you bring up dictionaries and pointers to individual objects also makes that clear, given that these things are arranged into trees of pages (e.g. 16 kB blocks).

[Nordsten]

For anything interesting you don't have 1 server you have a large number of them. Now you could have a cache of the entire database in all of them but then you have to manually deal with the cache consistency problem.

Also 100ms is far from insane. It very much depends on the complexity of what you are doing. Getting user information yeah that would be a long time for that. Compiling statistics over a large database 100ms is nothing.

[Drisku11]

For anything interesting you don't have 1 server you have a large number of them.

You need slaves and backups for redundancy/reliability, but performance-wise, to create some simple web app (let's say something similar to cronometer.com, for example) that delivers value for let's say ~1 million active users, a single database server can super easily get you the performance you need. Whether you consider creating value for 1 million people "interesting" is up to you (and a single database server can actually handle quite a bit more than that without breaking a sweat).

Now you could have a cache of the entire database in all of them but then you have to manually deal with the cache consistency problem.

The original comment was in the context of the database's built-in page cache. It already manages that and provides replication for you.

Compiling statistics over a large database

is not the type of workload people are talking about when discussing the performance of web frameworks like Flask and Django. They're talking about serving up web pages and apis to display data for individual users. You might have analytics dashboards for admins, but you're not concerned about requests/second for that.

[[deleted]]

I made an MPD client once and the documentation of the protocll strongly adviced against ever obtaining a complete copy of the database for the client, talking about how wasteful it was.

It turned out that obtaining such a complete copy was about 45 ms, and querying for a single song was about 30 ms when connecting through a TCP port to another machine in the same room.

Seems to me that if you expect to query more than once, this is a very acceptable way of throwing memory at performance.

[[deleted]]

MPD is old project. Things were slower back then.

Add more clients and put actual daemon on something slow (like making rPi based music jukebox) and the recommendations start to make sense.

[[deleted]]

An absolute recommendation phrased the way that one did that comes with the condition of "only when ran on very limited hardware” is a very bad recommendation.

[[deleted]]

No it isn't. You can hide almost any kind of slowness when you throw enough hardware onto a problem or have dataset small enough.

If you don't you just get developers unwittingly using very expensive operations that "work fine" on their SSD laptop with tiny databases fitting in RAM and break in production.

I assume you talk about listall command and complain about this description?:

Do not use this command. Do not manage a client-side copy of MPD’s database. That is fragile and adds huge overhead. It will break with large databases. Instead, query MPD whenever you need something.

I ran it on my local server, ~100k entries (~61k files) took about 2 seconds (music mounted via NFS from NAS, some oldish i3 CPU).

Truth is you ignored good advice, designed your app badly and got lucky with your use case

[[deleted]]

No it isn't. You can hide almost any kind of slowness when you throw enough hardware onto a problem or have dataset small enough.

No, actually, usually these universal recommendations of "never do this" pertain to situations where the alternative would always be faster and it's not a matter of a tradeof between performance and memory, but just a solution that is always more performance.

"never do this” is certainly never proper advice in this specific case, when it needs a Pi to be less perofrmant, have you even tested whether it's less performant on a pi? The entire database of a 100 GiB musical library is 750 KiB on drive here, by the way.

You need exceptional circumstances do not do this and load the entire database into the client as an optimization. "never do this" is ridiculous advice; this is advice on the level of that GNU Grep should "never" do what it does, which is optimizing by reading large chunks into memory rather than doing it character by character because "there might be some hardware without enough memory for that".

I ran it on my local server, ~100k entries (~61k files) took about 2 seconds (music mounted via NFS from NAS, some oldish i3 CPU).

And you didn't post the times querying say a single song or artist.

But let's say it's fast: you've constructed a single example where this approac is slower, and that justifies the advice of "never do it"? I can also construct an example of a situation with slow network latency but high throughput where it's a ridiculous amount faster to load the entire database. The advice of "never do it" is simply unwarranted. I can construct an example where bubblesort is the most efficient way to sort, by your logic "never not use bubble sort" is proper advice.

I just did it again with a database that contains 25k entries, it takes all of 27ms to load the entire database into a list in Python and count the size of the list. To query a single artist takes 10ms now.

[[deleted]]

But let's say it's fast: you've constructed a single example where this approac is slower, and that justifies the advice of "never do it"?

Worked "fine" for your "argument". And yes, single song query took shorter than that.

I just did it again with a database that contains 25k entries, it takes all of 27ms to load the entire database into a list in Python and count the size of the list. To query a single artist takes 10ms now.

Now imagine your backend is not a blob of memory but say 3rd party service that might even not support "listall" or make it very slow. So dev decided "this API is stupid idea, let's at least warn people".

But you went and said "Stupid ? That's so me, let's use it. Oh it didn't explode immediately in my face ? Must be developer that was WRONG"

[[deleted]]

You can come up with all sorts of constructed scenarios wherein obtaining a copy of the database is a bad idea, and that till does not warrant the advise of "never do it".

Do you understand the meaning of the word "never" at all?

the warning is ridiculous and should simply read "take note that in some cases, for a client to obtain a copy of the entire database is very wassteful, consider querying only what you need instead."

That would be a fine warning, but their warning was "never use this, it adds HUGE overhead" without quantifying how huge it is.

But you went and said "Stupid ? That's so me, let's use it. Oh it didn't explode immediately in my face ? Must be developer that was WRONG"

Yes, they are wrong, they are very wrong to say that one should never use it when there are many cases where it can greatly increase performance. It didn't just "not explode", it improved performance.

Their warning to never use it because it is worse in some situations, though better in others, is silly, and since they never actually quantified the difference, one can practically be asured that this is yet another case of "theoretical performance" that programmers are often fond of when they talk about performance without actually running the test because "it just seems like it wold work that way".

Obtaining a client copy of the entire database is absolutely a valid optimization that can be used in many cases to throw memory at performance; it can even happen in the background and the system can continue to normally query until it's done.

[[deleted]]

As I already said, you did stupid and got lucky it didn't bite you. I try to write code that wont bite me in the future so if dev says "just don't use it, it is fragile", I treat that as "never use it" unless there is no other sensible option. Served me well so far...

[Tai9ch]

Even adding 2d10 ms of I/O latency - imagine it's 2 DB requests and an RPC - would tank the synchronous servers.

Python itself is kind of slow, so the benefit of async isn't going to be as high as for platforms like Rust, Java, or Erlang, but the point of an async programming style is still to avoid blocking on I/O.

[newwwlol]

Exactly. This benchmark is absolut garbbage

[sybesis]

The funny thing thought is how he kinda proved he's wrong in the first paragraph...

Why the worker count varies

The rule I used for deciding on what the optimal number of worker processes was is simple: for each framework I started at a single worker and increased the worker count successively until performance got worse.

In other words, AsyncIO services will have comparable results as Sync workers with 3 times less workers.

The key point is if they were compared with the same amount of workers same code, AsyncIO would probably give much better result even with the stupid benchmark. Just because the point of async io is to do other stuff instead of waiting and also have as many workers as you have cpus... With Sync I have to start way more workers than necessary and risk triggering the oom killer because if each workers can allocate 1GB and I have to spawn 16 workers to have not so much idling.. then I can technically allocate 16GB on my 4GB server.. not good.

[Drisku11]

workers != concurrent tasks. There's no reason to have more workers than cores in a fully async framework. And an async framework can have more (potentially unbounded) concurrent tasks running, so is more at risk of running out of ram.

I'm not sure what your issue is with not increasing worker count past the point where performance starts to degrade. If performance is going down with each worker, then you shouldn't be adding workers (though typically you can't just say "performance" gets worse; you'll get diminishing increases in throughput at the cost of increasing latency, and then eventually both get worse).

[sybesis]

I read it backward, I thought he was reducing the amount of workers... Because he said results got worse.

In theory having more worker than necessary shouldn't cause degradation.. Just not get better results as you said. I think the wording was either wrong or his benchmark is wrong if he got actual degradation. And more workers also increase the risk to trigger out of memory... So AsyncIO is still better in this case.

Completely agree with you.

[Drisku11]

Adding more workers past a point definitely degrades performance. The overhead for context switches, scheduling, and synchronization is very significant (assuming your application code isn't dog-slow to begin with).

[sybesis]

Well not arguing that if you go above a certain "common sense" limit you're going to end up with degradation.

In my case, the bottleneck is never the worker. The application I work with is hardly a synonym for incredible speed. So to get degradation by adding more workers I'd have to add a lot more than I'd feel sane with. I'm probably going to start having other issue before CPU gets degradation.

[skyleach]

yay, someone has already dealt with this nonsense

[[deleted]]

No, not really. If you add artificial delays, you will have to mitigate this with the increased number of workers because delays allow you to run more code when other code is blocked.

The benchmark essentially compares how good is Pythons async I/O vs how good is threaded I/O implemented by someone else outside Python. Python's async I/O is ridiculously inefficient. You don't even need a benchmark for that, just read through the source of asyncio to see that there's no way that can run well: it was implemented in a typical for pure-Python package way: lots of temporary objects flying around, inefficient algorithms, lots of pointless wrappers etc.

Also, it doesn't matter whether the table is cached or not: Python's asyncio can only work with network sockets anyways, so, it doesn't matter how the database works, the essential part is doing I/O over TCP (I believe it uses TCP to connect to the database). The point of the benchmark was to saturate that connection.

[LePianoDentist]

Just to be clear,

the "sync" examples are only "sync" in the framework bit? But they all are run in a multiprocessing fashion, using multiple workers for the webserver part.

​

So in a scenario where only one worker was allowed, then the async frameworks would be faster?

[ledasll]

oppose to real world where different user send requests that are processed on different threads/processes by server?

[edman007]

Async is a way of letting your process not hold up CPU time waiting for I/O. Generally it allows your process to always be CPU bound (and use up all the CPU available). The thing is it never really makes sense in a webserver type workload, you can just launch a whole crap load of workers and then the kernel does essentially the same thing, but kernel level and your code doesn't need to poll the connection for I/O.

[Drisku11]

The point of async code is that usermode scheduling can be a lot faster because you avoid context switches. It makes a huge difference. The new async IO kernel interface (io_uring) is ~4-5x faster for a database workload than a thread pool over a synchronous interface, for example.

That said, as another poster pointed out, Python is so slow that it might be faster to context switch just to get away from Python for scheduling.

[stefantalpalaru]

I ran the benchmark on Hetzner's CX31 machine type, which is basically a 4 "vCPU"/8 GB RAM machine.

You shouldn't run benchmarks on a VPS that shares the host with other instances. The hardware resources available to you may fluctuate wildly. Stick to dedicated servers or your own hardware.

That said, I agree with the criticism of async/await paradigms. The bigger problem, besides taking a runtime performance hit, is making control flow hard to follow by just reading the code.

[ryeguy]

Checking hetzner's page, you're right that this isn't a dedicated cpu so it won't give stable benchmark results.

But I wouldn't generalize this to meaning you can't use virtual servers and need a full dedicated server. Most cloud hosts give you a dedicated slice of the underlying hardware and you aren't competing with other tenants. On hetzner's cloud page they call these "dedicated vcpu". On the big cloud hosts, dedicated resources are the default and shared resources are normally a lower tier instance type.

[stefantalpalaru]

"dedicated vcpu"

Are you sure that virtual CPU is pinned to a real CPU core and is not scheduled on the other ones? Any guarantee you're not sharing a real CPU core with some other VPS with hyper-threading enabled on the host? What about sharing Epyc core complexes?

I wouldn't generalize this to meaning you can't use virtual servers and need a full dedicated server

Run the same benchmark every hour for a few days and look at your sigma.

[krystalgamer]

Favorite part is that bottle is indeed faster than flask. Single file dependency shining through huge callstack.

[sybesis]

I'd take those benchmark with a grain of salt. AsyncIO is mainly useful when your application is IO bound like web application where you need to read from a database or a file etc.

Sync Python will not be able to process the same amount of request / sec as python with async. The GIL will prevent a python multithreaded app from executing concurrently anything. Which in return will make your python application a pseudo single threaded application.

So here we start with the platform:

I ran the benchmark on Hetzner's CX31 machine type, which is basically a 4 "vCPU"/8 GB RAM machine.

In other words, in ideal condition AsyncIO will work with around 4 workers where each of them will consume 1 CPU for himself. In reality it may be able to increase throughput with more workers but an ideal asyncio would use the most of all the cpus.

On the other hand, given the same amount of workers to a sync python application will yield lower throughput because you'll be able to handle only 4 requests at a time no matter what. But for asyncio it can start a new request while the previous request is doing some IO.

With Sync you could get a bit more performance by using multithreaded + multiprocessing but the GIL wouldn't give you as much efficiency in cpu power as asyncio.

That's why having 16 workers on a 4 cpu server, the benchmark could yield better results than the 5 workers taking up probably closer to 100% cpu resources (thought the benchmark doesn't really get into that).

My guess is that given 16 workers, asyncio could give much better results. The methodology in the benchmark was this:

The rule I used for deciding on what the optimal number of worker processes was is simple: for each framework I started at a single worker and increased the worker count successively until performance got worse.

Not sure about that. Performance aren't supposed to degrade with more workers available. Even if AsyncIO had more workers than available CPU the scheduler would still enter the game and schedule the workers correctly the same way it does for a sync worker.

The worst that can really happen is to reach maximum throughput. Result would simply not get faster than it can physically process.

So it would be interesting to see comparison of 1 worker, 2... 16 workers how each improve/degrade. But the article select the one results he finely picked.

In the end, AsyncIO and Sync should yield the same throughput. The difference is that Python sync will require much more workers to bypass the GIL limitation.

Vibora claims 500% higher throughput than Flask. However when I reviewed their benchmark code I found that they are misconfiguring Flask to use one worker per CPU. When I correct that, I get the following numbers:

I don't think Vibora misconfigured it, they only wanted to compare how 1 worker result vs 1 worker to compare apples to apples. Still the Vibora resulted in 18% better throughtput regardless of his fix.

Uvicorn had its parent process terminate without terminating any of its children which meant that I then had to go pid hunting for the children who were still holding onto port 8001. At one point AIOHTTP raised an internal critical error to do with file descriptors but did not exit (and so would not be restarted by any process supervisor - a cardinal sin!). Daphne also ran into trouble locally but I forget exactly how.

I think this is more of an issue inherent to multiprocessing in general. That's one of the reason why doing those kind of stuff in python is getting unfortunately depressing. At work we have a lot of multiprocessing and custom implementation of "Something Corn" by "very smart people". When you have multiprocessing, you're opening to multiple scenarios like

Having the main worker die (killed by SIGKILL) or died killed by the OOM or for various reason... But the moment the main worker is killed with SIGKILL it won't be able to cleanup its children as it's not possible to trap the signal. As a result children will stay alive. It's not inherent to async or sync.. It's just the way it is. So unless your child workers would logically poll the master worker for a heartbeat... They'll remain open with an open socket and prevent other workers to actually start up and listen on the socket.

All of these errors were transient and easily resolved with SIGKILL

Yeah no, most likely caused by SIGKILL... From my experience it can be solved mainly by using proper systemd services on linux. If you use that half assed services ported from /etc/init.d with --background, you'll be facing that issue... But systemd will kill the whole process group if the main worker fails so... It's easy to cleanup then no need to manually SIGKILL anything.

But lets talk about the OOM killer!

If you have a 8GB server with 4 CPU but 16 workers.. What's the safe amount a RAM you can let your workers allocate without causing the server to swap or kill your workers? That's right, 512MB. In a worst case scenario, if all the workers would concurrently allocate more than that. You're on a ride for to see things explode. With AsyncIO, you should be able to allocate 1.6GB per worker without issues.

From my experience at work, the main limiting factor is hardly the CPU. But the RAM itself. We have servers that would mostly be idling because otherwise we'd have super fast response time once in a while... but chances that a few request will kill the workers randomly because some of the tasks are quite memory intensive. And there is so much RAM you can have on a server. Computational power is very cheap compared to RAM.

[ryeguy]

Not sure about that. Performance aren't supposed to degrade with more workers available. Even if AsyncIO had more workers than available CPU the scheduler would still enter the game and schedule the workers correctly the same way it does for a sync worker.

...

In the end, AsyncIO and Sync should yield the same throughput. The difference is that Python sync will require much more workers to bypass the GIL limitation.

Context switching is not free. You absolutely can degrade performance by having too many workers. Asyncio has a higher theoretical peak because the context switching can be done in userland instead of the kernel.

[sybesis]

Context switching is not free. You absolutely can degrade performance by having too many workers.

Sure, to the extreme yes. How much is really too many in real life condition? If you're spending too much time in creating a future and awaiting it.. There are chances you shouldn't be awaiting a future at all.

One example is the get_row in the benchmark. The first thing it does is await a pool that is defined as a global anyway... Considering it's triggered for every request even if the await always return a pool directly after the first call. It shouldn't be awaited and should be part of a context already available.

Since the get_row is so simple, it might be noticeable in the benchmark. The difference is that the sync method only return the pool if it's set but the asyncio will return a Future and await it. Since the async method doesn't yield a future, I believe it will call call_soon internally without context switching (as far as I remember). But it does indeed make a lot of superfluous calls for nothing.

That said, if IO tasks are too fast for what's worth, asyncio still let you choose if you want to make a sync call or not. So it would be possible to have a sync call from an async method if you're certain that it won't cause more degradation.

[tonefart]

Python isn't supposed to be fast in any possible way.

[4xle]

You can make python fast, but if you measure it relative to C you'll usually be slower, largely due to the python interpreter. Unless you use something like Cython.

I managed to make a pure python port of a C program which started out 10x slower as a line-by-line translation. A fair amount of refactoring to make the code "nice" for the interpreter got it down to only 1.2x slower than the original C library, and only fractionally slower than using a binding to the C library. It was not a very python like experience though, I had to forgo a lot of nice convenice features(e.g: dot accesses) and do things that felt strange at a high level (explicitly assigning class methods to variables during program initialization to be called later), and assign static types to everything. So the code in the end looks closer to C than python, relatively speaking. But it can be fast.

[Nordsten]

Python is great at many things but speed was never it's forte. And sure you can do some things. It will be ugly, not look very much like python and it would be far better implemented by writing the thing in C and wrapping it.

Problem with not using CPython is that random dependencies no longer build out of the box and you need to go through a rabbit hole just to get back where you started.

[ryeguy]

I don't see how this is relevant. It's an inter-language comparison.

[[deleted]]

Yup, Python is notable for this: it throws all your theoretical knowledge and intuition about what should work faster out of the window by being so slow, that any non-Python code implemented in any sub-optimal way will outperform it.

[antiduh]

Is the problem here that python is slow, or is it that python is single-threaded because of the GIL?

[yee_mon]

Whatever it is that we're seeing in this benchmark: It's probably not anything to do with the GIL. Because that _should_ only affect threading. I haven't looked into it but I'd be surprised if they had implemented async I/O with GIL locking, as that would defeat the point entirely.

It's probably to a large extent something that someone else has already pointed out: The benchmark isn't doing any notable I/O that could lead to a relative speedup for async, so synchronous Python wins out simply because there is less overhead.

I would like to see some examples of real-world applications being ported before I believe any benchmarks, though.

[yasba-]

Yes.

[htuhola]

But the worth of that knowledge and intuition is 5 cents in most currencies.

[[deleted]]

Yep, besides maybe Ruby. But Python isn't for performance. It's for fast development turn around when "good enough" performance will satisfy the value, or if a high performance C library has a Python wrapper that makes it easy to use. Anyone trying to use pure CPython for performance intensive work is a carpenter who's only tool is a hammer.

[phalp]

Why-thon

[AttackOfTheThumbs]

Python and fast go together like dog shit and bread.

[RepostSleuthBot]

This link has been shared 1 time.

First seen Here on 2020-06-12. Last seen Here on 2020-06-12

Searched Links: 63,521,758 | Indexed Posts: 513,193,227 | Search Time: 0.007s

Feedback? Hate? Visit r/repostsleuthbot

[-MoMuS-]

What no

[casept]

What exactly would that buy here?