呼び出しが高価な場合にPythonで単一責任原則（SRP）を使用する

いくつかのベースポイント：

• Pythonのメソッド呼び出しは、その解釈された性質により「高価」です。理論的には、コードが十分に単純な場合、Pythonコードの分解は、読みやすさと再利用に加えてマイナスの影響を及ぼします（これは、ユーザーにとってはそれほどではなく、開発者にとって大きな利益です）。
• 単一責任原則（SRP）は、コードを読み取り可能に保ち、テストと保守が容易です。
• プロジェクトには、読み取り可能なコード、テスト、および時間パフォーマンスが必要な特別な種類の背景があります。

たとえば、いくつかのメソッド（x4）を呼び出すこのようなコードは、次のメソッド（1つ）よりも低速です。

from operator import add

class Vector:
    def __init__(self,list_of_3):
        self.coordinates = list_of_3

    def move(self,movement):
        self.coordinates = list( map(add, self.coordinates, movement))
        return self.coordinates

    def revert(self):
        self.coordinates = self.coordinates[::-1]
        return self.coordinates

    def get_coordinates(self):
        return self.coordinates

## Operation with one vector
vec3 = Vector([1,2,3])
vec3.move([1,1,1])
vec3.revert()
vec3.get_coordinates()

これと比較して：

from operator import add

def move_and_revert_and_return(vector,movement):
    return list( map(add, vector, movement) )[::-1]

move_and_revert_and_return([1,2,3],[1,1,1])

そのようなものを並列化する場合、パフォーマンスを失うのはかなり客観的です。これは単なる例です。私のプロジェクトには、数学などのミニルーチンがいくつかあります-作業はずっと簡単ですが、プロファイラーはそれを嫌っています。

固有の実装が直接影響するため、Pythonのパフォーマンスを損なうことなく、どのように、どこでSRPを採用しますか？

リリースのために物事をインラインにする何らかのプリプロセッサのような回避策はありますか？

それとも、Pythonはコードブレークダウンの処理だけでは不十分ですか？

Pythonは単にコードブレークダウンを完全に処理するのが苦手ですか？

残念ながら、Pythonは低速であり、関数をインライン化し、コードをくすることでパフォーマンスが大幅に向上するという逸話がたくさんあります。

回避策としてCythonがあります。これはPythonのコンパイル済みバージョンであり、はるかに高速です。

-編集コメントとその他の回答の一部に対処したかっただけです。それらの推力はおそらくPython固有のものではありませんが。しかし、より一般的な最適化。

1. 問題が発生するまで最適化しないで、ボトルネックを探す

   一般的に良いアドバイス。しかし、「通常の」コードは通常パフォーマンスが良いという前提があります。これは常にそうではありません。個々の言語とフレームワークにはそれぞれ独自の特異性があります。この場合、関数呼び出し。

2. わずか数ミリ秒で、他のものは遅くなります

   強力なデスクトップコンピューターでコードを実行している場合、シングルユーザーコードが数秒で実行される限り、おそらく気にする必要はありません。

   ただし、ビジネスコードは複数のユーザーで実行される傾向があり、負荷をサポートするために複数のマシンが必要です。コードの実行速度が2倍であれば、ユーザーの数は2倍、マシンの数は半分になります。

   マシンとデータセンターを所有している場合、通常、CPUパワーに大きなオーバーヘッドがかかります。コードの実行が少し遅い場合は、少なくとも2台目のマシンを購入する必要があるまで、それを吸収できます。

   必要な計算能力だけを使用し、それ以上使用しない最近のクラウドコンピューティングでは、非パフォーマンスコードに直接コストがかかります。

   パフォーマンスを改善することで、クラウドベースのビジネスの主な費用を大幅に削減することができ、パフォーマンスは真正面にあるべきです。

多くの潜在的なパフォーマンスの問題は実際には問題ではありません。 あなたが提起する問題はそれらの一つかもしれません。専門用語では、それらが実際の問題の時期尚早な最適化であることの証拠なしに、それらの問題について心配することを呼びます。

Webサービスのフロントエンドを作成する場合、ネットワーク経由でデータを送信するコストはメソッド呼び出しにかかる時間をはるかに超えるため、パフォーマンスは関数呼び出しの影響をあまり受けません。

ビデオ画面を1秒間に60回更新するタイトなループを作成している場合、問題になる可能性があります。しかし、その時点で、Pythonを使用してそれを実行しようとしている場合、あなたはより大きな問題を抱えていると主張します。

いつものように、あなたが見つける方法は測定することです。コードでパフォーマンスプロファイラーまたはいくつかのタイマーを実行します。実際に問題になっているかどうかを確認してください。

単一責任の原則は、法律または義務ではありません。それはガイドラインまたは原則です。ソフトウェア設計は常にトレードオフです。絶対的なものはありません。読みやすさや保守性を犠牲にして速度を犠牲にすることは珍しいことではないため、パフォーマンスの祭壇でSRPを犠牲にしなければならない場合があります。ただし、パフォーマンスの問題があることがわかっている場合を除き、そのトレードオフを行わないでください。

まず、いくつかの明確化：Pythonは言語です。Python言語で記述されたコードを実行できるいくつかの異なるインタープリターがあります。リファレンス実装（CPython）は通常、誰かが「Python」についてそれが実装であるかのように話すときに参照されるものですが、パフォーマンス特性について話すときは実装間で大きく異なる可能性があるため正確であることが重要です。

固有の実装が直接影響するため、Pythonのパフォーマンスを損なうことなく、どのように、どこでSRPを採用しますか？

ケース1.） 純粋なPythonモジュールのみに依存する純粋なPythonコード（<= Python言語バージョン3.5、3.6には「ベータレベルサポート」）がある場合、どこでもSRPを受け入れ、PyPyを使用して実行できます。PyPy（https://morepypy.blogspot.com/2019/03/pypy-v71-released-now-uses-utf-8.html）は、ジャストインタイムコンパイラー（JIT）を備え、機能を削除できるPythonインタープリターです実行されたコードをトレースして「ウォームアップ」するのに十分な時間がある限り、オーバーヘッドを呼び出します（数秒のIIRC）。**

CPythonインタープリターの使用に制限されている場合は、Cで記述された拡張機能に低速関数を抽出できます。これは、プリコンパイルされ、インタープリターのオーバーヘッドを受けません。どこでもSRPを使用できますが、コードはPythonとCに分割されます。SRPを選択的に放棄し、Pythonコードのみに固執するよりも保守性が良いか悪いかは、チームに依存しますが、 CPythonで解釈される最も最適化された純粋なPythonコードでさえ、間違いなく高速になります。Pythonの最速の数学ライブラリの多くは、この方法を使用しています（numpyおよびscipy IIRC）。これはケース2の良いセグエです...

ケース2.） C拡張機能を使用する（またはC拡張機能を使用するライブラリに依存する） Pythonコードがある場合、PyPyはそれらの記述方法に応じて役立つ場合と役に立たない場合があります。詳細については、http： //doc.pypy.org/en/latest/extending.htmlを参照してください。ただし、要約すると、CFFIのオーバーヘッドは最小限であり、CTypesは低速です（PyPyで使用すると、CPythonよりも遅くなる場合があります）。

Cython（https://cython.org/）は、私があまり経験のない別のオプションです。完全を期すためにこれに言及しているので、私の答えは「独立している」ことができますが、専門知識は主張しません。私の限られた使用から、PyPyで「無料」で得ることができる同じ速度の改善を得るために一生懸命に働かなければならないと感じました。コードを別の場所で再利用したり、その一部をライブラリに抽出したりすると、すべてのコードをPythonインタープリターで実行でき、Cythonで実行する必要はありません）。

Cythonに「ロック」されるのが怖いのですが、PyPy用に書かれたコードはCPythonでも実行できます。

**本番環境でのPyPyに関する追加の注意事項

大規模なコードベースでPyPyに「ロックイン」するという実際的な効果がある選択を行う場合は、十分に注意してください。一部の（非常に人気があり便利な）サードパーティライブラリは、前述の理由でうまく動作しないため、それらのライブラリのいずれかが必要であると気付いた場合、後で非常に難しい決定を下す可能性があります。私の経験は主に、PyPyを使用して、本番環境にごくわずかな複雑さを追加する企業環境でパフォーマンスに敏感な一部の（しかしすべてではない）マイクロサービスを高速化することです（すでに複数の言語がデプロイされており、いくつかは2.7 3.5とにかく実行）。

PyPyとCPythonの両方を使用すると、言語仕様自体によって行われた保証のみに依存し、いつでも変更される可能性のある実装の詳細に依存しないコードを書くことを定期的に余儀なくされました。そのような詳細について考えることは余分な負担になると思うかもしれませんが、私はそれが私の専門的な開発において価値があると感じ、Pythonエコシステム全体にとって「健康」だと思います。