説明 : Description

This document tries to explain the myths about Perl and overturn the FUD certain bodies try to spread.

このドキュメントは Perl についての与太話と特定の集団が広めようとしている FUD (Fear:恐怖, Uncertainty:不安, Doubt:疑念) を覆すことを説明することをトライします

略語 : Abbreviations

• M = Misconception or Myth

  
  M = 誤解 or 与太話



• R = Response

  
  R = 回答

インタプリタ vs. コンパイル : Interpreter vs. Compiled

• M:
  

  Each dynamic perl page hit needs to load the Perl interpreter and compile the script, then run it each time a dynamic web page is hit. This dramatically decreases performance as well as makes Perl an unscalable model since so much overhead is required to search each page.

  
  動的な perl のページはヒットするたびに Perl インタプリタをロードしてそのスクリプトをコンパイルする必要があり, 動的 web ページがヒットするたびにそれが走る. これはパフォーマンスを劇的に低下させるとともに各ページのサーチでとても多くのオーバーヘッドが要求されるので Perl を非スケーラブルなモデルにする.


• R:
  

  This myth was true years ago before the advent of mod_perl. mod_perl loads the interpreter once into memory and never needs to load it again. Each perl program is only compiled once. The compiled version is then kept into memory and used each time the program is run. In this way there is no extra overhead when hitting a mod_perl page.

  
  この与太話は mod_perl が出現する以前の何年か前は真実でした. mod_perl はインタプリタを 1 度メモリにロードして再びそのロードを必要とすることはありません. 各 perl プログラムは 1 度のみコンパイルされます. コンパイル済みのバージョンはメモリにキープされてプログラムが走るたびに使われます. この方法で mod_perl ページがヒットしたときに余分なオーバーヘッドはありません.

インタプリタ vs. コンパイル (より凄惨な詳細) : Interpreter vs. Compiled (More Gory Details)

• R:
  

  Compiled code always has the potential to be faster than interpreted code. Ultimately, all interpreted code needs to eventually be converted to native instructions at some point, and this is invariably has to be done by a compiled application.

  
  コンパイル型コードは常にインタープリタ型コードよりも速くなる可能性をもっています. 最終的に, すべてのインタープリタ型コードは結局どこかの時点でネイティブ命令にコンバートされることを必要としていて, これは変わることなくコンパイル型アプリケーションによって行われなければなりません.
  

  That said, an interpreted language CAN be faster than a comprable native application in certain situations, given certain, common programming practices. For example, the allocation and de-allocation of memory can be a relatively expensive process in a tightly scoped compiled language, wheras interpreted languages typically use garbage collectors which don't need to do expensive deallocation in a tight loop, instead waiting until additional memory is absolutely necessary, or for a less computationally intensive period. Of course, using a garbage collector in C would eliminate this edge in this situation, but where using garbage collectors in C is uncommon, Perl and most other interpreted languages have built-in garbage collectors.

  
  とはいえ, インタプリタ型言語は, 信頼できる所与の, 一般的なプログラミング手法の特定のシチュエーションでは同等のネイティブアプリケーションよりも高速になりえます. 例えば, メモリのアロケート (# 割当て) とデアロケート (# 解除) はタイトにスコープされたコンパイル型言語では比較的高価なプロセスになりますが, 一方でインタプリタ型言語は典型的にはタイトループで高価なデアロケートを必要とせず, かわりに追加のメモリが絶対的に必要となるか, 計算負荷が少ない期間まで待つガベージコレクタを使います. もちろん, C でのガベージコレクタの使用はこのシチュエーションにおけるエッジ (# 優位性) を排除するでしょうが, C でガベージコレクションを使うことは非一般的であり, Perl や他のほとんどのインタプリタ型言語はビルトインのガベージコレクタをもっています.
  

  It is also important to point out that few people use the full potential of their modern CPU with a single application. Modern CPUs are not only more than fast enough to run interpreted code, many processors include instruction sets designed to increase the performance of interpreted code.

  
  またひとつのアプリケーションでモダンな CPU のフルポテンシャルを使うのはわずかな人々にすぎないことを指摘することも重要です. モダンな CPU はインタプリタ型言語の実行に十分高速なだけでなく, 多くのプロセッサはインタプリタ型言語のパフォーマンスを向上させるために設計された命令セットを含んでいます.
  

Perl は過度にメモリインテンシブで非スケーラブルである : Perl is overly memory intensive maiking it unscalable

• M:
  

  Each child process needs the Perl interpreter and all code in memory. Even with mod_perl httpd processes tend to be overly large, slowing performance, and requiring much more hardware.

  
  各 child (# 子) プロセスは Perl インタプリタとすべてのコードがメモリ内にあることを必要とする. mod_perl であっても httpd プロセスは過度に大きく, パフォーマンスは遅く, より多くのハードウェアを要求する傾向がある.


• R:
  

  In mod_perl the interpreter is loaded into the parent process and shared between the children. Also, when scripts are loaded into the parent and the parent forks a child httpd process, that child shares those scripts with the parent. So while the child may take 6MB of memory, 5MB of that might be shared meaning it only really uses 1MB per child. Even 5 MB of memory per child is not uncommon for most web applications on other languages.

  
  mod_perl でインタプリタは parent (# 親) プロセスにロードされその child たちの間でシェアされます. また, スクリプトがある parent にロードされてその parent が child httpd プロセスをフォークすると, その child はそれらのスクリプトを parent とシェアします. ですから child は 6MB のメモリをとるかもしれませんが, その 5MB はシェアされるでしょうからそれは実際には child ごとに 1 MB のみを使うことを意味します. child ごとに 5MB のメモリであったとしても他の言語の web アプリケーションでは珍しいことではありません.
  

  Also, most modern operating systems support the concept of shared libraries. Perl can be compiled as a shared library, enabling the bulk of the perl interpreter to be shared between processes. Some executable formats on some platforms (I believe ELF is one such format) are able to share entire executable TEXT segments between unrelated processes.

  
  また, ほとんどのモダンなオペレーティングシステムは共有ライブラリのコンセプトをサポートします. Perl は共有ライブラリとしてコンパイルすることができ, perl インタプリタの大部分はプロセス間で共有できるようになっています. 一部プラットフォームでの一部実行可能フォーマット (私は ELF (# Executable and Linking Format) はそのようなフォーマットのひとつだと思います) は関連しないプロセス間での実行可能な TEXT セグメント全体の共有ができるようになっています.

追加のチューニングのアドバイス : More Tuning Advice:

• Stas Bekman's Performance Guide (https://perl.apache.org/docs/1.0/guide/performance.html)

Perl での開発はサポート, またはツールが十分はでない (与太話) : Not enough support, or tools to develop with Perl. (Myth)

• R:
  

  Of all web applications and languages, Perl arguable has the most support and tools. CPAN is a central repository of Perl modules which are freely downloadable and usually well supported. There are literally thousands of modules which make building web apps in Perl much easier. There are also countless mailing lists of extremely responsive Perl experts who usually respond to questions within an hour. There are also a number of Perl development environments to make building Perl Web applications easier. Just to name a few, there is Apache::ASP, Mason, embPerl, ePerl, etc...

  
  すべての web アプリケーションと言語で, Perl はもっとも多くのサポートとツールをもっていると主張できます. CPAN は Perl モジュールの中央リポジトリでありそれらはフリーでダウンロードできて通常はよくサポートされています. 文字通り何千ものモジュールがありそれらは Perl でより簡単に web アプリを構築できるようにします. また通常は 1 時間で質問にレスポンスする極めてレスポンシブな Perl エキスパートの数えきれないメーリングリストもあります. Perl の Web アプリケーションの構築を簡単にする Perl 開発環境もいくつかあります. いくつかの例をいうなら, Apache::ASP, Mason, embPerl, ePerl, etc です...

Perl とてもよくスケールするならば, どうして大きなサイトはそれを使わないのか ? (与太話) : If Perl scales so well, how come no large sites use it? (myth)

• R:
  

  Actually, many large sites DO use Perl for the bulk of their web applications. Here are some, just as an example: e-Toys, CitySearch, Internet Movie Database( http://imdb.com ), Value Click ( http://valueclick.com ), Paramount Digital Entertainment, CMP ( http://cmpnet.com ), HotBot Mail/HotBot Homepages, and DejaNews to name a few. Even Microsoft has taken interest in Perl via http://www.activestate.com/.

  
  実際は, 多くの大きなサイトはその web アプリケーションの大部分で Perl を利用しています. こちらは, まさにそのような例の一部: そのいくつかをあげるなら e-Toys, CitySearch, Internet Movie Database( http://imdb.com ), Value Click ( http://valueclick.com ), Paramount Digital Entertainment, CMP ( http://cmpnet.com ), HotBot Mail/HotBot Homepages, それから DejaNews. Microsoft でさえ http://www.activestate.com/ を介して Perl に関心をもっています.

Perl は mod_perl でさえ, 常に C より遅い : Perl even with mod_perl, is always slower then C.

• R:
  

  The Perl engine is written in C. There is no point arguing that Perl is faster than C because anything written in Perl could obviously be re-written in C. The same holds true for arguing that C is faster than assembly.

  
  Perl エンジンは C で書かれています. Perl が C よりも高速であることを論じる意味はありません Perl で書かれたものはなんであれば当然 C で書き直すことができるからです. C がアセンブリよりも速いことを論じることと同じことです.
  

  There are two issues to consider here. First of all, many times a web application written in Perl CAN be faster than C thanks to the low level optimizations in the Perl compiler. In other words, its easier to write poorly written C then well written Perl. Secondly its important to weigh all factors when choosing a language to build a web application in. Time to market is often one of the highest priorities in creating a web application. Development in Perl can often be twice as fast as in C. This is mostly due to the differences in the language themselves as well as the wealth of free examples and modules which speed development significantly. Perl's speedy development time can be a huge competitive advantage.

  
  ここで考慮する 2 つの課題があります. まず最初に, Perl コンパイラの低レベル最適化のおかげで Perl で書いた web アプリケーションは C より速くなることがあります. 言い換えれば, 下手に C を書くよりも良い感じに Perl で書くほうが簡単なのです. 次に web アプリケーションを構築するための言語を選択する場合はすべてのファクタを熟考することが重要です. Time To Market (# 製品化されるまでの時間) は web アプリケーションの作成において多くの場合で 最優先事項のひとつです. Perl での開発はしばしば C の 2 倍の速さにできます. これは概ね言語そのものの違いとともにフリーの例や著しく開発を高速化するモジュールの豊富さに起因します. Perl の迅速な開発時間は非常に大きな競争力のアドバンテージになります.

Java は Perl の必要性を排除する : Java does away with the need for Perl.

• M:
  

  Perl had its place in the past, but now there's Java and Java will kill Perl.

  
  過去において Perl はその場所にいたが, いまそこには Java がいて Java は Perl をキルする.


• R:
  

  Java and Perl are actually more complimentary languages then competitive. Its widely accepted that server side Java solutions such as JServ, JSP and JRUN, are far slower then mod_perl solutions (see next myth). Even so, Java is often used as the front end for server side Perl applications. Unlike Perl, with Java you can create advanced client side applications. Combined with the strength of server side Perl these client side Java applications can be made very powerful.

  
  Java と Perl は実際のところは競合するというよりもより補完的 (#? s/more compli/more comple/) な言語です. JServ, JSP や JRUN のような, サーバサイドの Java ソリューションが mod_perl ソリューションよりもはるかに遅いことは広く受けいれられています (次の与太話を参照). それでいてなお, Java はサーバサイドの Perl アプリケーションのフロントエンドとしてよく使われます. Perl とは違って, Java であればあなたは高度なクライアントサイドのアプリケーションを作成できます. サーバサイドの Perl の強みと組み合わせることでそれらクライアントサイドの Java アプリケーションをよりパワフルにできます.

Perl は高度なクライアントサイドのアプリケーションを作成できない : Perl can't create advanced client side applications

• R:
  

  True. There are some client side Perl solutions like PerlScript in MSIE 5.0, but all client side Perl requires the user to have the Perl interpreter on their local machine. Most users do not have a Perl interpreter on their local machine. Most Perl programmers who need to create an advanced client side application use Java as their client side programming language and Perl as the server side solution.

  
  真実です. MSIE 5.0 での PerlScript のようなクライアントサイドの Perl ソリューションはありますが, すべてのクライアントサイド Perl はユーザが Perl インタプリタをそのローカルマシン上にもっていることを要求します. ほとんどのユーザはそのローカルマシン上に Perl インタプリタをもっていません.
  高度なクライアントサイドアプリケーションの作成を必要とするほとんどの Perl プログラマはそのクライアントサイドのプログラミング言語として Java をサーバサイドのソリューションとして Perl を使います.

ASP は Perl を web プログラミング言語として廃れさせる : ASP makes Perl obsolete as a web programming language.

• M:
  

  With Perl you have to write individual programs for each set of pages. With ASP you can write simple code directly within HTML pages. ASP is the Perl killer.

  
  Perl であなたは各ページセットのために個別のプログラムを書かねばならない. ASP であなたは HTML ページに直接シンプルにコードを書ける. ASP は Perl キラーである (# ここでの ASP は MS の Active Server Pages).


• R:
  

  There are many solutions which allow you to embed Perl in web pages just like ASP. In fact, you can actually use Perl IN ASP pages with PerlScript. Other solutions include: Mason, Apache::ASP, ePerl, embPerl and XPP. Also, Microsoft and ActiveState have worked very hard to make Perl run equally well on NT as Unix. You can even create COM modules in Perl that can be used from within ASP pages. Some other advantages Perl has over ASP: mod_perl is usually much faster then ASP, Perl has much more example code and full programs which are freely downloadable, and Perl is cross platform, able to run on Solaris, Linux, SCO, Digital Unix, Unix V, AIX, OS2, VMS MacOS, Win95-98 and NT to name a few.

  
  ちょうど ASP のようにあなたが Perl を web ページに埋め込めるようになる多くのソリューションがあります. 現実に, あなたは PerlScript で Perl IN ASP pages を実際に使うことができます. 他のソリューションはこれらを含みます: Mason, Apache::ASP, ePerl, embPerl それから XPP. また, Microsoft と ActiveState は NT 上でも Unix と同様に Perl が走るようにとても頑張っています. あなたは ASP ページ内から使える COM モジュールさえ Perl で作成できます. Perl が ASP を超えているその他のアドバンテージ: mod_perl は通常 ASP よりもはるかに高速, Perl はより多くのコード例やフリーでダウンロードできるフルプログラムをもつ , そして Perl はクロスプラットフォームで, いくつかを挙げるなら Solaris, Linux, SCO, Digital Unix, Unix V, AIX, OS2, VMS MacOS, Win95-98 それから NT 上で走る.
  

  Also, Benchmarks show that embedded Perl solutions outperform ASP/VB on IIS by several orders of magnitude. Perl is a much easier language for some to learn, especially those with a background in C or C++.

  
  また, ベンチマークは埋め込まれた Perl ソリューションが IIS 上の ASP/VB よりも桁違いに優れていることを示します. Perl はとても学びやすい言語です, 特にバックグランドが C や C++ の人々は.

クレジット : Credits

Thanks to the mod_perl list for all of the good information and criticism. I'd especially like to thank,

すべてのグッドな情報と非難のための mod_perl リストに感謝です. 私が特に感謝したいのは,

• Stas Bekman


• Thornton Prime


• Chip Turner


• Clinton


• Joshua Chamas


• John Edstrom


• Rasmus Lerdorf


• Nedim Cholich


• Mike Perry < http://www.icorp.net/icorp/feedback.htm >



• Finally, I'd like to thank Robert Santos , CyberNation's lead Business Development guy for inspiring this document.

  
  最後に, 私はこのドキュメントを触発してくれた CyberNation の リードビジネス開発担当者, Robert Santos に感謝します.

メンテナ : Maintainers

Maintainer is the person(s) you should contact with updates, corrections and patches.

• Contact the mod_perl docs list

作者 : Authors

• Adam Pisoni

Only the major authors are listed above. For contributors see the Changes file.

NEXT

次回は、「 Documentation / Tutorials 」を確認する前に、本文中で言及のあった More Tuning Advice "Stas Bekman's Performance Guide" のリンク先「 Documentation / 1.0 / mod_perl 1.0 User Guide / Performance Tuning 」を「 mod_perl 」公式サイト (https://perl.apache.org/index.html) より確認します。


参考情報は書籍「 続・初めての Perl 改訂版 」, 「 Effective Perl 第 2 版 」を中心に perldoc, Wikipedia および各 Web サイト。それと詳しい先輩。

目次 - Perl Index