argra****@users*****
argra****@users*****
2012年 10月 3日 (水) 03:08:35 JST
Index: docs/perl/5.10.1/perlperf.pod
diff -u docs/perl/5.10.1/perlperf.pod:1.4 docs/perl/5.10.1/perlperf.pod:1.5
--- docs/perl/5.10.1/perlperf.pod:1.4 Tue Jul 3 03:47:00 2012
+++ docs/perl/5.10.1/perlperf.pod Wed Oct 3 03:08:35 2012
@@ -172,20 +172,18 @@
=end original
-It is clear that inline code is going to be faster than subroutine or method
-calls, because there is less overhead, but this approach has the disadvantage
-of being less maintainable and comes at the cost of greater memory usage -
-there is no such thing as a free lunch. If you are searching for an element in
-a list, it can be more efficient to store the data in a hash structure, and
-then simply look to see whether the key is defined, rather than to loop through
-the entire array using grep() for instance. substr() may be (a lot) faster
-than grep() but not as flexible, so you have another trade-off to access. Your
-code may contain a line which takes 0.01 of a second to execute which if you
-call it 1,000 times, quite likely in a program parsing even medium sized files
-for instance, you already have a 10 second delay, in just one single code
-location, and if you call that line 100,000 times, your entire program will
-slow down to an unbearable crawl.
-(TBT)
+オーバーヘッドが少ないので、インラインコードはサブルーチンやメソッドの
+呼び出しより早いのは明らかですが、この手法は保守性が悪くなってメモリ消費が
+大きくなると言う欠点があります - フリーランチのようなものはありません。
+一覧の要素を探すとき、例えば配列全体を grep() を使ってループを
+するのではなく、データをハッシュ構造に保管して、キーがあるかどうかを調べる
+方がより効率的です。
+substr() は grep() (とても)早くなりますが、それほど柔軟ではないので、
+アクセスするのにもう一つのトレードオフがあります。
+例えば中くらいのサイズのファイルをパースするような、1,000 回呼び出される
+0.01 秒かかる行が単一の行ですでに 10 秒の遅延があるかもしれませんし、
+その行が 100,000 回呼び出されるなら、プログラム全体が耐えられないぐらい
+遅くなります。
=begin original
@@ -206,21 +204,21 @@
=end original
-Using a subroutine as part of your sort is a powerful way to get exactly what
-you want, but will usually be slower than the built-in I<alphabetic> C<cmp> and
-I<numeric> C<E<lt>=E<gt>> sort operators. It is possible to make multiple
-passes over your data, building indices to make the upcoming sort more
-efficient, and to use what is known as the C<OM> (Orcish Maneuver) to cache the
-sort keys in advance. The cache lookup, while a good idea, can itself be a
-source of slowdown by enforcing a double pass over the data - once to setup the
-cache, and once to sort the data. Using C<pack()> to extract the required sort
-key into a consistent string can be an efficient way to build a single string
-to compare, instead of using multiple sort keys, which makes it possible to use
-the standard, written in C<c> and fast, perl C<sort()> function on the output,
-and is the basis of the C<GRT> (Guttman Rossler Transform). Some string
-combinations can slow the C<GRT> down, by just being too plain complex for it's
-own good.
-(TBT)
+ソートの一部としてサブルーチンを使うことは、したいことを正確にするための
+強力な方法ですが、普通は組み込みの I<文字比較> の C<cmp> および
+I<数値比較> の C<E<lt>=E<gt>> ソート演算子よりも遅いです。
+データに対して複数パスを行って、ソートをより効率的にするためのインデックスを
+構築し、予めソートキーをキャッシュするために C<OM> (Orcish Maneuver) として
+知られてるものを使うことができます。
+キャッシュの検索は、いい考えですが、それ自身データに対する 2 重パスを
+強制することでスローダウンの元となり得ます - キャッシュの設定で一度、
+データのソートでもう一度です。
+必要なソートキーを永続的な文字列に展開するために C<pack()> を使うのは、
+複数のソートキーを使わずに比較するための単一の文字列を構築する効率的な
+方法になり得ます; これにより出力に標準で C<c> で書かれていて高速な
+Perl の C<sort()> 関数を使えるようになり、C<GRT> (Guttman Rossler Transform)
+の基礎となります。
+一部の文字列比較は、単に複雑すぎるので C<GRT> を低下させます。
=begin original
@@ -238,18 +236,17 @@
=end original
-For applications using database backends, the standard C<DBIx> namespace has
-tries to help with keeping things nippy, not least because it tries to I<not>
-query the database until the latest possible moment, but always read the docs
-which come with your choice of libraries. Among the many issues facing
-developers dealing with databases should remain aware of is to always use
-C<SQL> placeholders and to consider pre-fetching data sets when this might
-prove advantageous. Splitting up a large file by assigning multiple processes
-to parsing a single file, using say C<POE>, C<threads> or C<fork> can also be a
-useful way of optimizing your usage of the available C<CPU> resources, though
-this technique is fraught with concurrency issues and demands high attention to
-detail.
-(TBT)
+データベースバックエンドを使うアプリケーションで、標準の
+C<DBIx> 名前空間は物事をぴりっとしたものにし続けるように助けようとします;
+特に可能な限り遅くまでデータベースに問い合わせ I<しない> ようにしますが、
+常に選択したライブラリに付属している文書を読んでください。
+データベースを扱う開発者が直面する多くの問題で気にするべきことは、
+常に C<SQL> プレースホルダを使うことと、利点がある分かるときにはデータ集合の
+プリフェッチを考慮することです。
+大きなファイルを、C<POE>, C<threads>, C<fork> と言ったものを使って
+単一のファイルをパースする複数のプロセスに割り当てることで分割することも、
+利用可能な C<CPU> リソースの仕様を最適化する有用な方法になり得ますが、
+このテクニックは並列性の問題に直面し、詳細に関して高い注目を必要とします。
=begin original
@@ -260,11 +257,10 @@
=end original
-Every case has a specific application and one or more exceptions, and there is
-no replacement for running a few tests and finding out which method works best
-for your particular environment, this is why writing optimal code is not an
-exact science, and why we love using Perl so much - TMTOWTDI.
-(TBT)
+それぞれのケースには特定のアプリケーションと一つまたは複数の例外があり、
+いくつかテストを実行して、特定の環境にとってどの手法が最良かを見つけることに
+代わるものはありません; これは、最適なコードを書くことが正確な科学ではない
+理由であり、我々が Perl を使うのをとても愛している理由です - TMTOWTDI。
=head1 BENCHMARKS
@@ -307,15 +303,15 @@
=end original
-This sort of code can be a real eyesore to read, as well as being very
-sensitive to typos, and it's much clearer to dereference the variable
-explicitly. We're side-stepping the issue of working with object-oriented
-programming techniques to encapsulate variable access via methods, only
-accessible through an object. Here we're just discussing the technical
-implementation of choice, and whether this has an effect on performance. We
-can see whether this dereferencing operation, has any overhead by putting
-comparative code in a file and running a C<Benchmark> test.
-(TBT)
+この種類のコードは読むと目が疲れ、タイプミスに弱く、変数を明示的に
+デリファレンスすることで遥かに明確になります。
+変数アクセスをメソッド経由でカプセル化して、オブジェクトを通してのみ
+アクセス可能にすると言うオブジェクト指向プログラミングのテクニックを
+使う問題を横に避けておきます。
+ここでは単に選択する技術実装に関して、そしてこれが性能が向上するかどうかを
+議論しています。
+このデリファレンス操作がかなりのコードをファイルに置くことによる
+オーバーヘッドがあるのかを C<Benchmark> テストで見てみます。
=begin original
@@ -362,13 +358,12 @@
=end original
-It's essential to run any timing measurements a sufficient number of times so
-the numbers settle on a numerical average, otherwise each run will naturally
-fluctuate due to variations in the environment, to reduce the effect of
-contention for C<CPU> resources and network bandwidth for instance. Running
-the above code for one million iterations, we can take a look at the report
-output by the C<Benchmark> module, to see which approach is the most effective.
-(TBT)
+
+時間計測は、平均を安定させるために十分な回数行うことが重要です;
+さもなければそれぞれの実行は、例えば C<CPU> リソースの競合の効果や
+ネットワーク帯域のような環境の変化によって自然に変動します。
+どの手法が最も効果的を見るために、上述のコードを 100 万回繰り返して、
+C<Benchmark> モジュールによって出力された報告を見てみます。
$> perl dereference
@@ -388,14 +383,13 @@
=end original
-The difference is clear to see and the dereferencing approach is slower. While
-it managed to execute an average of 628,930 times a second during our test, the
-direct approach managed to run an additional 204,403 times, unfortunately.
-Unfortunately, because there are many examples of code written using the
-multiple layer direct variable access, and it's usually horrible. It is,
-however, miniscully faster. The question remains whether the minute gain is
-actually worth the eyestrain, or the loss of maintainability.
-(TBT)
+違いははっきりと見え、デリファレンスの手法はより遅いです。
+これはテスト中 1 秒間に平均して 628,930 回実行しましたが、直接手法は
+残念ながらさらに 204,403 回実行しています。
+残念ながら、複数層の直接変数アクセスを使ったコード例がたくさんあるので、
+これは普通は恐ろしいものです。
+しかし、これはほんの少し速いです。
+問題は、ほんの少しの向上が疲れ目と保守性の喪失の価値があるかです。
=head2 Search and replace or tr
@@ -436,11 +430,10 @@
=end original
-We can put that into a test file which we can run to check which approach is
-the fastest, using a global C<$STR> variable to assign to the C<my $str>
-variable so as to avoid perl trying to optimize any of the work away by
-noticing it's assigned only the once.
-(TBT)
+どの手法が一番早いかをチェックするために、実行するテストファイルにこれを
+置きます; perl が一度しか代入されないことを気付くことで処理しないように
+最適化しようとすることを避けるために、C<my $str> 変数へ代入するために
+グローバルな C<$STR> 変数を使います。
=begin original
@@ -655,14 +648,12 @@
この由緒あるモジュールは 10 年以上 Perl コードプロファイリングのデファクト
スタンダードでしたが、21 世紀になって色々なその他のモジュールに
置き換えられています。
-Although you're recommended to
-evaluate your tool from the several mentioned here and from the CPAN list at
-the base of this document, (and currently L<Devel::NYTProf> seems to be the
-weapon of choice - see below), we'll take a quick look at the output from
-L<Devel::DProf> first, to set a baseline for Perl profiling tools. Run the
-above program under the control of C<Devel::DProf> by using the C<-d> switch on
-the command-line.
-(TBT)
+いくつかここで言及されたり、この文書の基礎となる CPAN リストからツールを
+評価することを勧められていますが、(そして現在のところ L<Devel::NYTProf> が
+選択する武器のようですが - 後述します)、Perl プロファイリングツールの
+基本となる L<Devel::DProf> からの出力をまず簡単に見てみます。
+コマンドラインで C<-d> オプションを使うことで C<Devel::DProf> の制御下で
+プログラムを実行します。
$> perl -d:DProf wordmatch -f perl5db.pl
@@ -727,11 +718,11 @@
=end original
-C<dprofpp> will produce some quite detailed reporting on the activity of the
-C<wordmatch> program. The wallclock, user and system, times are at the top of
-the analysis, and after this are the main columns defining which define the
-report. Check the C<dprofpp> docs for details of the many options it supports.
-(TBT)
+C<dprofpp> は C<wordmatch> プログラムの活動のかなり詳細な報告を出力します。
+壁時計時間、ユーザーとシステム時間が分析の先頭にあり、その後は報告を
+定義する定義で主な列です。
+対応している多くのオプションの詳細については C<dprofpp> の文書を
+チェックしてください。
=begin original
@@ -754,10 +745,9 @@
=end original
同じプログラムの他のプロファイラによる結果も見てみましょう:
-C<Devel::Profiler>, a drop-in Perl-only replacement for C<Devel::DProf>. The
-usage is very slightly different in that instead of using the special C<-d:>
-flag, you pull C<Devel::Profiler> in directly as a module using C<-M>.
-(TBT)
+C<Devel::Profiler> は C<Devel::DProf> の Perl 専用のドロップインです。
+使用法は特殊な C<-d:> フラグを使うのとはほんの少し違って、
+C<Devel::Profiler> を C<-M> を使ってモジュールとして直接読み込みます。
$> perl -MDevel::Profiler wordmatch -f perl5db.pl
@@ -781,10 +771,9 @@
=end original
-C<Devel::Profiler> generates a tmon.out file which is compatible with the
-C<dprofpp> program, thus saving the construction of a dedicated statistics
-reader program. C<dprofpp> usage is therefore identical to the above example.
-(TBT)
+C<Devel::Profiler> は C<dprofpp> プログラムと互換性のある tmon.out ファイルを
+生成するので、専用の統計読み込みプログラムの構築を省略できます。
+従って C<dprofpp> の使用法は上述の例と同じです。
$> dprofpp
@@ -818,17 +807,18 @@
=end original
-Interestingly we get slightly different results, which is mostly because the
-algorithm which generates the report is different, even though the output file
-format was allegedly identical. The elapsed, user and system times are clearly
-showing the time it took for C<Devel::Profiler> to execute it's own run, but
-the column listings feel more accurate somehow than the ones we had earlier
-from C<Devel::DProf>. The 102% figure has disappeared, for example. This is
-where we have to use the tools at our disposal, and recognise their pros and
-cons, before using them. Interestingly, the numbers of calls for each
-subroutine are identical in the two reports, it's the percentages which differ.
-As the author of C<Devel::Proviler> writes:
-(TBT)
+興味深いことに少し異なった結果が得られました; その理由のほとんどは、
+出力ファイル形式は同一とされているにも関わらず、報告を生成するアルゴリズムが
+異なることです。
+経過時間とユーザー+システム時間は明らかに C<Devel::Profiler> が自身の実行で
+かかった時間を表示してますが、列一覧は先に C<Devel::DProf> で得られたものより
+いくらかより正確なものに感じられます。
+例えば、102% の図は消えました。
+これが、ツールを使ってみて、それらを使う前にそれらの利点と欠点を認識する
+必要があるところです。
+興味深いことに、それぞれのサブルーチンの呼び出し回数は二つの報告で
+同じですが、百分率は異なっています。
+C<Devel::Proviler> の作者が書いているように:
...running HTML::Template's test suite under Devel::DProf shows output()
taking NO time but Devel::Profiler shows around 10% of the time is in output().
@@ -850,7 +840,6 @@
=end original
-See also
C<mod_perl> に C<Devel::Profiler> フックを付ける
C<Devel::Apache::Profiler> も参照してください。
@@ -865,11 +854,9 @@
=end original
-The C<Devel::SmallProf> profiler examines the runtime of your Perl program and
-produces a line-by-line listing to show how many times each line was called,
-and how long each line took to execute. It is called by supplying the familiar
-C<-d> flag to Perl at runtime.
-(TBT)
+C<Devel::SmallProf> プロファイラは Perl プログラムの実行時間を調べて、
+それぞれの行が何回呼び出されたかをしめす行単位の一覧を出力します。
+これは実行時に Perl に親しんだ C<-d> フラグを指定することで呼び出されます。
$> perl -d:SmallProf wordmatch -f perl5db.pl
@@ -891,9 +878,9 @@
=end original
-C<Devel::SmallProf> writes it's output into a file called F<smallprof.out>, by
-default. The format of the file looks like this:
-(TBT)
+C<Devel::SmallProf> は出力を、デフォルトでは F<smallprof.out> と呼ばれる
+ファイルに書き込みます。
+ファイルの形式は以下のようなものです:
<num> <time> <ctime> <line>:<text>
@@ -905,10 +892,9 @@
=end original
-When the program has terminated, the output may be examined and sorted using
-any standard text filtering utilities. Something like the following may be
-sufficient:
-(TBT)
+プログラムが終了したとき、出力は任意の標準テキストフィルタリング
+ユーティリティを使って検査とソートが行われます。
+以下のようなもので十分でしょう:
$> cat smallprof.out | grep \d*: | sort -k3 | tac | head -n20
@@ -943,12 +929,13 @@
=end original
-You can immediately see a slightly different focus to the subroutine profiling
-modules, and we start to see exactly which line of code is taking the most
-time. That regex line is looking a bit suspicious, for example. Remember that
-these tools are supposed to be used together, there is no single best way to
-profile your code, you need to use the best tools for the job.
-(TBT)
+サブルーチンプロファイリングモジュールとは少し異なったフォーカスであることが
+すぐに分かります; そして正確にコードのどの行が一番時間がかかるかを
+見始めます。
+例えば、正規表現行は少し疑わしく見えます。
+これらのツールは互いに使われることを想定されていて、コードを
+プロファイリングする単一の最良の方法というのはなく、仕事によって最良の
+ツールを使う必要があると言うことを忘れないでください。
=begin original
@@ -973,7 +960,7 @@
C<Devel::FastProf> はもう一つの Perl 行プロファイラです。
これは、例えば C<Devel::SmallProf> などよりも速い行プロファイラとして
C<C> で書かれました。
-C<Devel::FastProf> を使うには、 Perl に C<-d> オプションを指定します:
+C<Devel::FastProf> を使うには、Perl に C<-d> オプションを指定します:
$> perl -d:FastProf wordmatch -f perl5db.pl
@@ -996,10 +983,10 @@
=end original
-C<Devel::FastProf> writes statistics to the file F<fastprof.out> in the current
-directory. The output file, which can be specified, can be interpreted by using
-the C<fprofpp> command-line program.
-(TBT)
+C<Devel::FastProf> は現在のディレクトリのファイル F<fastprof.out> に
+統計情報を書き込みます。
+指定可能な出力ファイルは C<fprofpp> コマンドラインプログラムを使って
+解釈されます。
$> fprofpp | head -n20
@@ -1025,13 +1012,11 @@
=end original
-Straightaway we can see that the number of times each line has been called is
-identical to the C<Devel::SmallProf> output, and the sequence is only very
-slightly different based on the ordering of the amount of time each line took
-to execute, C<if ( $debug ) { > and C<my $message = shift;>, for example. The
-differences in the actual times recorded might be in the algorithm used
-internally, or it could be due to system resource limitations or contention.
-(TBT)
+直ちに、各行が呼び出された回数が C<Devel::SmallProf> の出力と同じで、並びは
+各行の実行時間順を基にして ほんの少しだけ異なる(例えば C<if ( $debug ) { > と
+C<my $message = shift;>) ことがわかります。
+実際に記録されている時間の違いは内部で使われているアルゴリズムかも
+しれませんし、システムリソースの制限や衝突によるかもしれません。
=begin original
@@ -1071,8 +1056,8 @@
これは C<c> で書かれていて、おそらく Perl で利用可能な最速の
プロファイラです。
素晴らしさの一覧はまだ続きます。
-これで十分でしょうから、どのように動作するかを見てみましょう - 単に
-親しんだ C<-d> スイッチを使って、コードを実行します。
+これで十分でしょうから、どのように動作するかを見てみましょう - 単に親しんだ
+C<-d> スイッチを使って、コードを実行します。
$> perl -d:NYTProf wordmatch -f perl5db.pl
@@ -1095,12 +1080,12 @@
=end original
-C<NYTProf> will generate a report database into the file F<nytprof.out> by
-default. Human readable reports can be generated from here by using the
-supplied C<nytprofhtml> (HTML output) and C<nytprofcsv> (CSV output) programs.
-We've used the unix sytem C<html2text> utility to convert the
-F<nytprof/index.html> file for convenience here.
-(TBT)
+C<NYTProf> はデフォルトではファイル F<nytprof.out> にレポートデータベースを
+生成します。
+人間が読める報告は、提供される C<nytprofhtml> (HTML 出力) または
+C<nytprofcsv> (CSV 出力) プログラムを使うことでここから生成されます。
+F<nytprof/index.html> ファイルをここで便利なように変換するために unix
+システムの C<html2text> ユーティリティを使っています。
$> html2text nytprof/index.html
@@ -1138,10 +1123,9 @@
=end original
-The first part of the report already shows the critical information regarding
-which subroutines are using the most time. The next gives some statistics
-about the source files profiled.
-(TBT)
+報告の最初の部分は既に、どのサブルーチンが一番時間がかかっているかという
+重要な情報を表示しています。
+以下はプロファイリングしたソースファイルに関するいくつかの統計情報です。
Source Code Files -- ordered by exclusive time then name
|Stmts |Exclusive|Avg. |Reports |Source File |
@@ -1186,13 +1170,12 @@
=end original
-At this point, if you're using the I<html> report, you can click through the
-various links to bore down into each subroutine and each line of code. Because
-we're using the text reporting here, and there's a whole directory full of
-reports built for each source file, we'll just display a part of the
-corresponding F<wordmatch-line.html> file, sufficient to give an idea of the
-sort of output you can expect from this cool tool.
-(TBT)
+この点で、I<html> レポートを使っているなら、サブルーチン単位と行単位の
+詳細への様々なリンクをクリックできます。
+ここではテキストレポートを使っていて、それぞれのソースファイルに対して
+ビルドされたレポートファイルがディレクトリにたくさんあるので、対応する
+F<wordmatch-line.html> ファイルの一部だけを表示します; この素晴らしいツールで
+どのような出力が得られるかの考えを与えるには十分です。
$> html2text nytprof/wordmatch-line.html
@@ -1302,17 +1285,16 @@
Perl モジュールは性能分析者が持っている唯一の道具というわけではなく、
ソートについて軽く見てみる次の例のように、C<time> のようなシステムツールも
見落とすべきではありません。
-Many books, theses and
-articles, have been written about efficient sorting algorithms, and this is not
-the place to repeat such work, there's several good sorting modules which
-deserve taking a look at too: C<Sort::Maker>, C<Sort::Key> spring to mind.
-However, it's still possible to make some observations on certain Perl specific
-interpretations on issues relating to sorting data sets and give an example or
-two with regard to how sorting large data volumes can effect performance.
-Firstly, an often overlooked point when sorting large amounts of data, one can
-attempt to reduce the data set to be dealt with and in many cases C<grep()> can
-be quite useful as a simple filter:
-(TBT)
+効率的なソートアルゴリズムについて書かれている多くの多くの本、論文、記事が
+あり、ここはそのようなことを繰り返す場所ではありません; 調べてみる価値のある
+いくつかのよいソートモジュールもあります: C<Sort::Maker>, C<Sort::Key> が
+思い浮かびます。
+しかし、まだデータ集合のソートに関連する問題の Perl 特有の解釈に関して
+いくつか観測できる可能性があるので、大量のデータがどのように性能に
+影響するかに関する例をいくつか示します。
+最初に、大量のデータをソートするときにしばしば見落とされる点は、扱うデータ
+集合を減らそうと出来ることと、多くの場合 C<grep()> が単純なフィルタとして
+かなり有用であるということです:
@data = sort grep { /$filter/ } @incoming
@@ -1328,14 +1310,13 @@
=end original
-A command such as this can vastly reduce the volume of material to actually
-sort through in the first place, and should not be too lightly disregarded
-purely on the basis of it's simplicity. The C<KISS> principle is too often
-overlooked - the next example uses the simple system C<time> utility to
-demonstrate. Let's take a look at an actual example of sorting the contents of
-a large file, an apache logfile would do. This one has over a quarter of a
-million lines, is 50M in size, and a snippet of it looks like this:
-(TBT)
+このようなコマンドは最初に実際にソートする量をとても減らすことが出来、
+単純性の原則だけであまり簡単に無視するべきではありません。
+C<KISS> 原則はあまりにも見逃されています - 次の例はデモに単純なシステム
+C<time> ユーティリティを使います。
+大きなファイルの内容をソートするという実際の例を見てみましょう; apache の
+ログファイルを使ってみます。
+これは 25 万行 50M バイトを超えますが、その一部は以下のようなものです:
=begin original
@@ -1472,7 +1453,7 @@
=end original
-プログラムは実行にちょうど 17 壁時計時間ほどかかりました。
+プログラムは実行にちょうど 17 壁時計秒ほどかかりました。
C<time> 出力の異なった値に注意して、いつも同じものを使い、それぞれの値の
意味を混乱しないことが重要です。
@@ -1674,14 +1655,14 @@
=end original
-The problem is that this code will always be parsed and executed, even when the
-debug level set in the logging configuration file is zero. Once the debug()
-subroutine has been entered, and the internal C<$debug> variable confirmed to
-be zero, for example, the message which has been sent in will be discarded and
-the program will continue. In the example given though, the \%INC hash will
-already have been dumped, and the message string constructed, all of which work
-could be bypassed by a debug variable at the statement level, like this:
-(TBT)
+問題は、例えログ設定ファイルのデバッグレベルがゼロでも、このコードは常に
+パースされて実行されることです。
+例えば、一度 debug() サブルーチンに入って、内部の C<$debug> 変数が
+ゼロであることを確認すると、送られたメッセージは捨てられてプログラムは
+続行します。
+しかし、上述の例では、\%INC はすでにダンプされていて、メッセージ文字列は
+構築されていて、このような作業の全ては以下のような文レベルの
+デバッグ変数によって回避されるかもしれません:
logger->debug( "A logging message via process-id: $$ INC: " . Dumper(\%INC) ) if $DEBUG;
@@ -1754,12 +1735,12 @@
=end original
-In the one case the code, which does exactly the same thing as far as
-outputting any debugging information is concerned, in other words nothing,
-takes 14 seconds, and in the other case the code takes one hundredth of a
-second. Looks fairly definitive. Use a C<$DEBUG> variable BEFORE you call the
-subroutine, rather than relying on the smart functionality inside it.
-(TBT)
+ある場合では、デバッグ情報を出力するのと全く同じ、言い換えると何もしない
+コードが 14 秒掛かっています。
+他の場合ではコードは 0.01 秒掛かっています。
+かなり明確に見えます。
+内部のスマートな機能に依存するのではなく、サブルーチンを呼び出す前に
+C<$DEBUG> 変数を使ってください。
=head2 Logging if DEBUG (constant)
@@ -1834,12 +1815,13 @@
=end original
-The C<DEBUG> constant wipes the floor with even the C<$debug> variable,
-clocking in at minus zero seconds, and generates a "warning: too few iterations
-for a reliable count" message into the bargain. To see what is really going
-on, and why we had too few iterations when we thought we asked for 100000, we
-can use the very useful C<B::Deparse> to inspect the new code:
-(TBT)
+C<DEBUG> 定数は C<$debug> 変数に対してでも床掃除をして、マイナスゼロ秒として
+記録しています。
+さらに "warning: too few iterations for a reliable count" メッセージを
+生成します。
+何が本当に起きているか、そしてなぜ 100000 を聞いたときに反復が
+少なすぎるのかを見るために、新しいコードを調べるためにとても有用な
+C<B::Deparse> を使えます:
$> perl -MO=Deparse ifdebug-constant
@@ -1870,10 +1852,10 @@
=end original
-The output shows the constant() subroutine we're testing being replaced with
-the value of the C<DEBUG> constant: zero. The line to be tested has been
-completely optimized away, and you can't get much more efficient than that.
-(TBT)
+出力は、テストしている constant() サブルーチンが C<DEBUG> 定数の値: ゼロに
+置き換えられていることを示しています。
+テストしたラインは完全に最適化されていて、これ以上すごく効率的にすることは
+できません。
=head1 POSTSCRIPT