[Pythonjp-checkins] [python-doc-ja] push by songo****@gmail***** - whatsnew/2.7 最適化終わり on 2011-11-17 05:12 GMT

Back to archive index

pytho****@googl***** pytho****@googl*****
2011年 11月 17日 (木) 14:13:48 JST


Revision: 79c85a87f4ad
Author:   Naoki INADA  <inada****@klab*****>
Date:     Wed Nov 16 21:12:49 2011
Log:      whatsnew/2.7 最適化終わり
http://code.google.com/p/python-doc-ja/source/detail?r=79c85a87f4ad

Modified:
  /whatsnew/2.7.rst

=======================================
--- /whatsnew/2.7.rst	Wed Nov 16 09:55:47 2011
+++ /whatsnew/2.7.rst	Wed Nov 16 21:12:49 2011
@@ -851,47 +851,45 @@
  最適化
  -------------

-Several performance enhancements have been added:
-
-* A new opcode was added to perform the initial setup for
-  :keyword:`with` statements, looking up the :meth:`__enter__` and
-  :meth:`__exit__` methods.  (Contributed by Benjamin Peterson.)
-
-* The garbage collector now performs better for one common usage
-  pattern: when many objects are being allocated without deallocating
-  any of them.  This would previously take quadratic
-  time for garbage collection, but now the number of full garbage  
collections
-  is reduced as the number of objects on the heap grows.
-  The new logic only performs a full garbage collection pass when
-  the middle generation has been collected 10 times and when the
-  number of survivor objects from the middle generation exceeds 10% of
-  the number of objects in the oldest generation.  (Suggested by Martin
+.. Several performance enhancements have been added:
+
+いくつかの場面でパフォーマンスが向上しています。
+
+* :keyword:`with` 文の初期セットアップを行うための新しいオペコードが追加さ 
れました。
+  :meth:`__enter__` と :meth:`__exit__` メソッドの検索を行います。
+  (Contributed by Benjamin Peterson.)
+
+* たくさんのオブジェクトを開放せずに確保していくという、よくある使い方の
+  1つにおいて、GCのパフォーマンスが向上しました。
+  以前はこの場合にGCにかかる時間はオブジェクトの数の2乗に比例していました。
+  現在はフルGCの数は増えたヒープ上のオブジェクトの数に比例しています。
+  新しい方式では、3世代中2世代目に対するGCが10回実行されたうえで、
+  2世代目から3世代目に移ったオブジェクトの数が3世代目のオブジェクトの数の
+  10%を超えたときにフルGCが発生します。(Suggested by Martin
    von Löwis and implemented by Antoine Pitrou; :issue:`4074`.)

-* The garbage collector tries to avoid tracking simple containers
-  which can't be part of a cycle. In Python 2.7, this is now true for
-  tuples and dicts containing atomic types (such as ints, strings,
-  etc.). Transitively, a dict containing tuples of atomic types won't
-  be tracked either. This helps reduce the cost of each
-  garbage collection by decreasing the number of objects to be
-  considered and traversed by the collector.
+* GCが循環参照になりえないシンプルなコンテナ型の追跡を避けるようになりまし 
た。
+  Python 2.7 では、アトミックな型(整数、文字列など)のみを含むタプルと辞書は
+  追跡されません。推移的に、アトミックな型のみを含むタプルを含む辞書も、
+  同じく追跡されません。
+  これにより、GCによって巡回されチェックされるオブジェクトの数が減るので、
+  GCのコストを減らすことができます。
    (Contributed by Antoine Pitrou; :issue:`4688`.)

-* Long integers are now stored internally either in base 2**15 or in base
-  2**30, the base being determined at build time.  Previously, they
-  were always stored in base 2**15.  Using base 2**30 gives
-  significant performance improvements on 64-bit machines, but
-  benchmark results on 32-bit machines have been mixed.  Therefore,
-  the default is to use base 2**30 on 64-bit machines and base 2**15
-  on 32-bit machines; on Unix, there's a new configure option
-  :option:`--enable-big-digits` that can be used to override this default.
-
-  Apart from the performance improvements this change should be
-  invisible to end users, with one exception: for testing and
-  debugging purposes there's a new structseq :data:`sys.long_info` that
-  provides information about the internal format, giving the number of
-  bits per digit and the size in bytes of the C type used to store
-  each digit::
+* 多倍長整数の内部格納方式が、 2**15 ベースと 2**30 ベースのどちらかを
+  ビルド時に選択するようになりました。
+  以前は常に 2**15 ベースで格納していました。
+  2**30 ベースにすると 64bit マシンに置いては確実にパフォーマンスが向上しま 
すが、
+  32bit マシンではパフォーマンスが向上する場合も低下する場合もあります。
+  なので、デフォルトでは 64bit マシンでは 2**30 ベースで、 32bit マシンでは
+  2**15 ベースになるようになります。
+  Unix では新しい configure オプションとして :option:`--enable-big-digis`
+  が追加され、このデフォルトの選択をオーバーライドできるようになっていま 
す。
+
+  この変更はパフォーマンスの向上以外の形ではユーザーに見えないはずですが、
+  1つだけ例外があります。テストとデバッグを目的とし 
て、 :data:`sys.long_info`
+  というデータが追加され、内部フォーマットとして digit あたりの
+  ビット数と、それに使うCのデータ型のバイト数の情報を提供します::

       >>> import sys
       >>> sys.long_info
@@ -899,54 +897,53 @@

    (Contributed by Mark Dickinson; :issue:`4258`.)

-  Another set of changes made long objects a few bytes smaller: 2 bytes
-  smaller on 32-bit systems and 6 bytes on 64-bit.
+  その他の変更により、多倍長整数オブジェクトのサイズは数バイト小さくなりま 
した。
+  32bit システムでは 2byte, 64bit システムでは 6byte 小さくなりました。
    (Contributed by Mark Dickinson; :issue:`5260`.)

-* The division algorithm for long integers has been made faster
-  by tightening the inner loop, doing shifts instead of multiplications,
-  and fixing an unnecessary extra iteration.
-  Various benchmarks show speedups of between 50% and 150% for long
-  integer divisions and modulo operations.
+* 多倍長整数の除算アルゴリズムが、内部のループの軽量化や乗算からシフト演算 
への
+  置き換え、不要なイテレーションの削除により高速化されました。
+  いくつかのベンチマークによると、多倍長整数の剰余演算は 50% から 150% 高速 
化されています。
    (Contributed by Mark Dickinson; :issue:`5512`.)
-  Bitwise operations are also significantly faster (initial patch by
-  Gregory Smith; :issue:`1087418`).
-
-* The implementation of ``%`` checks for the left-side operand being
-  a Python string and special-cases it; this results in a 1-3%
-  performance increase for applications that frequently use ``%``
-  with strings, such as templating libraries.
+  ビット演算も高速化されています。(initial patch by
+  Gregory Smith; :issue:`1087418`)
+
+* ``%`` の実装が、左側のオペランドが文字列型かどうかをチェックして
+  その場合の処理を特殊化しました。これにより文字列に対して ``%`` を頻繁に使 
う、
+  テンプレートライブラリなどのアプリケーションのパフォーマンスが1-3%向上し 
ます。
    (Implemented by Collin Winter; :issue:`5176`.)

-* List comprehensions with an ``if`` condition are compiled into
-  faster bytecode.  (Patch by Antoine Pitrou, back-ported to 2.7
+* ``if`` 条件付きのリスト内包表記がより高速なバイトコードにコンパイル
+  されるようになりました。(Patch by Antoine Pitrou, back-ported to 2.7
    by Jeffrey Yasskin; :issue:`4715`.)

-* Converting an integer or long integer to a decimal string was made
-  faster by special-casing base 10 instead of using a generalized
-  conversion function that supports arbitrary bases.
+* 整数や多倍長整数から10進文字列への変換を、任意の基数をサポートした
+  汎用の変換関数を使う代わりに10進数に特殊化した処理を行うことで
+  高速化しました。
    (Patch by Gawain Bolton; :issue:`6713`.)

-* The :meth:`split`, :meth:`replace`, :meth:`rindex`,
-  :meth:`rpartition`, and :meth:`rsplit` methods of string-like types
-  (strings, Unicode strings, and :class:`bytearray` objects) now use a
-  fast reverse-search algorithm instead of a character-by-character
-  scan.  This is sometimes faster by a factor of 10.  (Added by
+* 文字列等(str, unicode, :class:`bytearray`) の
+  :meth:`split`, :meth:`replace`, :meth:`rindex`, :meth:`rpartition`,
+  :meth:`rsplit` メソッドが、1文字ずつのスキャンの代わりに高速な逆方向
+  スキャンアルゴリズムを使うようになりました。
+  これにより、場合によっては10倍レベルの高速化になります。(Added by
    Florent Xicluna; :issue:`7462` and :issue:`7622`.)

-* The :mod:`pickle` and :mod:`cPickle` modules now automatically
-  intern the strings used for attribute names, reducing memory usage
-  of the objects resulting from unpickling.  (Contributed by Jake
+* :mod:`pickle` と :mod:`cPickle` モジュールが、属性名に使われている
+  文字列を自動的にインターンするようになりました。これにより unpickle 後の
+  オブジェクトのメモリ使用量が減ります。(Contributed by Jake
    McGuire; :issue:`5084`.)

-* The :mod:`cPickle` module now special-cases dictionaries,
-  nearly halving the time required to pickle them.
+* :mod:`cPickle` モジュールが辞書に対する特殊化を行い、 pickle にかかる
+  時間をおよそ半分に減らしました。
    (Contributed by Collin Winter; :issue:`5670`.)

  .. ======================================================================

-New and Improved Modules
-========================
+.. New and Improved Modules
+
+新しいモジュールと機能が追加されたモジュール
+=============================================

  As in every release, Python's standard library received a number of
  enhancements and bug fixes.  Here's a partial list of the most notable



Pythonjp-checkins メーリングリストの案内
Back to archive index