From e76216dd2657599db93420557bccb977f8aba3de Mon Sep 17 00:00:00 2001 From: Zaar Hai Date: Tue, 5 Mar 2019 02:04:16 +1000 Subject: [PATCH] Clarification about possible performance hit (#64) * Furether technical details towards #33. * :memo: Update note about previous async frameworks --- docs/async.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/docs/async.md b/docs/async.md index 6013d217e..e55fe5fae 100644 --- a/docs/async.md +++ b/docs/async.md @@ -377,6 +377,10 @@ All that is what powers FastAPI (through Starlette) and what makes it have such When you declare a *path operation function* with normal `def` instead of `async def`, it is run in an external threadpool that is then awaited, instead of being called directly (as it would block the server). +If you are coming from another async framework that does not work in the way described above and you are used to define trivial compute-only *path operation functions* with plain `def` for a tiny performance gain (about 100 nanoseconds), please note that in **FastAPI** the effect would be quite opposite. In these cases, it's better to use `async def` unless your *path operation functions* use code that performs blocking IO. + +Still, in both situations, chances are that **FastAPI** will still be faster than (or at least comparable to) your previous framework. + ### Dependencies The same applies for dependencies. If a dependency is a standard `def` function instead of `async def`, it is run in the external threadpool.