4

さまざまな言語のメモリ管理と、モバイル アプリの UX でスタッターが発生するため、Objective-C がメモリを管理していないという事実について読んでいました。

Python の GC は循環参照を処理しますが、ARC は循環参照を処理しないことを私は知っています。

ARC はまったくガベージ コレクターではないことを知っているため、メイン プログラムの実行を停止してメモリ管理を実行することはありません。

Python はハイブリッド アプローチを使用できますか? ARC のいくつかの利点を活用し、同時に GC の実行頻度を減らして (または短時間で)、循環参照を引き続き処理できるようにしますか?

それとも、Python コミュニティ内でそのような試みが行われているのでしょうか?

編集：Pythonが参照カウントを使用していることは知っていますが、私が知る限り、参照が0に落ちたオブジェクトはすぐにメモリから削除されません（ARCはそうします）。そのオブジェクトによって占有されているメモリをすぐに解放することで、メモリの少ない環境で Python がより適切になるかどうか疑問に思っています。その場合、GC の実行頻度が低下する可能性があるため、スレッドの中断が少なくなります。どちらも、UX に関する限り、モバイル アプリケーションにとって理想的です。

4

1 に答える 1

7

私が知る限り、Objective-C の ARC は、最終的に、CPython の参照カウントから循環参照の処理を除いたものと同じものを提供します。ARC は、プログラマーではなく、Objective-C コンパイラーが参照カウント コードを自動的に挿入することを意味するために (再) 発明された単なる派手な新しい名前です。

この回答の目的のために、CPython を Objective-C で書き直すことができると仮定しましょう (これは非現実的です)。明示的な参照カウントで ARC を使用すると、次のようになります。

  • よりシンプルなコード。

  • 循環収集なし。

  • 正しいコードを保証します。CPython の参照カウントには、ごくまれにクラッシュを引き起こす可能性のあるいくつかの既知の問題と、おそらく不明な問題があります。一部はLib/test/crashers/これに基づいています。

  • 少し遅いコード。実際、参照カウンターを実際に操作する必要のないケースを見つけることに関して、コンパイラーは通常、人間ほど賢くはありません。

PyPy 開発者として、私自身の経験を報告できます。過去のある時点で同じことを試みました。つまり、コンパイル中に参照カウント コードが自動的に挿入されました。ただし、高度な最適化を行わないとコードが大幅に遅くなるため、このアプローチを断念しました。代わりに、単純な「実際の」ガベージ コレクション (GC) システムを使用します。CPython の参照カウントよりも優れたパフォーマンスが得られます。したがって、コンパイラ作成者への私自身のアドバイスは、必要なコードを自動的に挿入できるコンパイラが必要な場合は、多くの優れた GC のいずれかを使用する方がはるかに優れているということです。最後に確認したところ、この点に関して LLVM のサポートはまだほとんどゼロでした。

于 2013-07-20T08:48:29.747 に答える