Liran Nuna added the comment:
> A coroutine detection is a relatively slow check.
> I don't think we need to do it in `functools.lru_cache`.
Wouldn't a coroutine check only happen during decoration time? To successfully
solve this easily and efficiently, we only really need t
New submission from Liran Nuna :
lru_cache is a very useful method but it does not work well with coroutines
since they can only be executed once.
Take for example, the attached code (test-case.py) - It will throw a
RuntimeError because you cannot reuse an already awaited coroutine
Liran Nuna added the comment:
> That's still doable with contextvars. You just need a custom mock-like object
> (or library) that stores its settings/state in a context variable.
contextvars only work with asyncio, what about the iterator case?
In addition, you can't possibly expect a
Liran Nuna added the comment:
> You should try to use the contextvars module that was specifically created to
> handle local context state (for tasks & coroutines).
Yury, from my original report:
> I'm aware that this particular problem could be solved with the new context
Liran Nuna added the comment:
I would like to stress this issue happens with iterators as well, and this
isn't a unique issue to asyncio only.
I would like to propose four new magic methods for context managers to solve
this: __pause__, __resume__, __apause__ and __aresume__ which
New submission from Liran Nuna :
An interesting property of async programming is that execution order is
nondeterministic and async function "pause" and "resume" execution as events
come in.
This can play havok with context managers, especially ones that wrap a global
Liran Nuna <liran...@gmail.com> added the comment:
Yuri, Those speed improvements are awesome and I'm really excited about them,
performance is slowly starting to match asynq and would make us migrating our
code to async/await more feasable!
Today, python3.6.4 was re
Liran Nuna <liran...@gmail.com> added the comment:
Yury, thank you very much for circling back. I wish I could be more helpful in
pursuing performance improvements.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Liran Nuna <liran...@gmail.com> added the comment:
> Also I suggest you to try uvloop
Sadly, uvloop does not offer any noticeable improvement in performance for us.
Our usage is very similar to the "benchmarks" I posted - we don't do any actual
async I/O because a
Liran Nuna <liran...@gmail.com> added the comment:
> which makes them faster in some specific micro-benchmarks
I'm not talking about micro-benchmarks, we are actively using asynq in
production. Recent efforts to migrate to async/await have hit a major
performance hit - our respo
Liran Nuna <liran...@gmail.com> added the comment:
The PR is merely a finding I ran into while benchmarking. In my executions I
saw a consistent ~3-5% performance increase.
At my company we are attempting to migrate from asynq to asyncio but
performance suffers (our servers response
Liran Nuna <liran...@gmail.com> added the comment:
Added comparable benchmark in asynq
--
Added file: https://bugs.python.org/file47314/batch_asynq.py
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
New submission from Liran Nuna <liran...@gmail.com>:
The performance of async/await is very low when compared to similar code that
implements similar functionality via iterators, such as Quora's asynq library
(https://github.com/quora/asynq/tree/master/asynq).
Based on my benchmarks,
Changes by Liran Nuna <liran...@gmail.com>:
--
nosy: +Liran Nuna
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29051>
___
__
14 matches
Mail list logo
