Wiriting cdef extension classes for `Future` objects for speeding up `_SyncSocketReaderFuture` and `_SyncSocketWriterFuture`
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 20/100
- issue の種類
- リファクタリング
- 明瞭さ
- 説明が足りない
- 活発さ
- 停滞
- 技術スタック
- python
調査の方向性
この提案は _SyncSocketReaderFuture と _SyncSocketWriterFuture を対象とし、aio_Future を Cython 拡張クラスで置き換えるか削除することを提案しています。リポジトリのファイル、テスト、ベンチマーク、具体的な受け入れ基準のいずれも指定されていないため、まずはこれらの Future 実装と、それらを利用する asyncio.isfuture の箇所を探してください。Future に期待される動作を維持しながら速度向上を実証できれば完了となりますが、issue ではその測定方法が定義されていません。
索引モデルが issue の本文から書いたものです。
説明
I have been brainstorming ways of going about optimizing some objects in uvloop and winloop's code and I think I have an idea for making these
objects run slightly faster and I was wondering if I could make the same optimizations on uvloop's end when I am done implementing this on winloop's side. My main objective involves wrapping _SyncSocketReaderFuture and _SyncSocketWriterFuture to a faster object such as a cdef extension so that these can be more optimized as well as possibly looking into getting rid of aio_Future if proven to be faster since programmers should rely on what asyncio.isfuture does and not isinstance(fut, asyncio.Future) which should be discouraged allowing for new optimizations to be introduced.
The other workaround idea was asking cpython for a CAPI Capsule which I wrote an issue for already but I think if this idea is proven successful we can skip that entirely and use this instead.
# My concept is still a little incomplete so take this with a grain of salt.
cimport cython
from .loop cimport Loop # Ignore for now I am just needing this since I am working with cyright in vscode to help with my thinking process.
import sys
from cpython.exc cimport PyErr_SetString, PyErr_SetObject
from cpython.ref cimport Py_CLEAR
from cpython.object cimport PyObject
from cpython.list cimport PyList_GET_SIZE, PyList_Append
from cpython.tuple cimport PyTuple_GET_ITEM
from cpython.contextvars cimport PyContext_CopyCurrent
from asyncio import format_helpers
include "includes/stdlib.pxi"
# In CPython these are enums so lets make some enums
# to get off from strings for speed.
cdef enum fut_state:
STATE_PENDING = 0
STATE_CANCELLED = 1
STATE_FINISHED = 2
cdef extern from "Python.h":
"""
#define PyObject_isNULL(obj) obj == NULL
#define DoTheEvilTrick(obj, to) \\
to = obj; obj = NULL
"""
# Checks to see if PyObject* is null by as a normal object
# without recasting itself.
bint PyObject_isNULL(object obj)
# Don't let cython toy with refs...
void DoTheEvilTrick(object obj, object to)
int PyException_SetTraceback(object ex, object tb) except -1
object PyException_GetContext(object ex)
void PyException_SetContext(object ex, object ctx)
object PyException_GetCause(object ex)
void PyException_SetCause(object ex, object cause)
object PyException_GetTraceback(object ex)
# Here is a comptable version of asyncio.Future forked over from
# python 3.15 which is currently in research mode but
# we can make changes if needed.
# I'll mix a bit of CPython in so that we can be speedy.
cdef class Future:
"""This class is *almost* compatible with concurrent.futures.Future.
Differences:
- This class is not thread-safe.
- result() and exception() do not take a timeout argument and
raise an exception when the future isn't done yet.
- Callbacks registered with add_done_callback() are always called
via the event loop's call_soon().
- This class is not compatible with the wait() and as_completed()
methods in the concurrent.futures package.
"""
cdef:
# obviously since we don't want this exposed for external editing.
Loop fut_loop
# Skipping fut_context0 and fut_callback0 to prevent
# complexity we can optimize further later...
list fut_callbacks
object fut_exception
object fut_exception_tb
object fut_result
object fut_source_tb
object fut_cancel_msg
object fut_cancelled_exc
object fut_awaited_by
fut_state fut_state
bint fut_awaited_by_is_set
bint fut_is_task
unsigned int fut_log_tb
unsigned int fut_blocking
- 主要言語
- Cython
- スター
- 11.9k
- フォーク
- 615
- PR マージ指標
- 30日以内にマージされた PR はありません
コントリビューションガイド
このリポジトリのコントリビューションガイドは索引されていません
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
MagicStack/uvloop のほかの issue
-
License not clear オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
MagicStack/uvloop#759 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
MagicStack/uvloop#741 · リアクション 2 件 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
MagicStack/uvloop#702 · コメント 8 件 · リアクション 9 件 ·
-
難易度 3/5 1〜2日 初心者へのやさしさ 68/100
MagicStack/uvloop#763 ·
-
難易度 3/5 1〜2日 初心者へのやさしさ 68/100
MagicStack/uvloop#760 ·
MagicStack/uvloop の issue をすべて見る
似ている issue
-
type/automation type/performance
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
TheManticoreProject/Manticore#1380 ·
-
enhancement new
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
-
P3 sonic-vpp
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
sonic-net/sonic-buildimage#29662 ·