オートバイがタンクを交換できなかった理由、またはREG.RU Webサイトのテンプレート::ツールキットからテキスト:: Xslateへの翻訳

主要なインターネットプロジェクトの背後には、自動化された情報システムと、商品やサービスを販売するWebサイトがあります。 プロジェクトが大きくなるほど、サイトのロジックが複雑になり、負担が大きくなります。 サイトの「パワー」を高め、ページの応答時間を短縮するタスクがあります。 そのようなシステムを作成するすべての人と同様に、 サイトの速度を調整するセッションを定期的に実施しています。 私たちは到達可能なすべてを最適化しています。 ある段階で、彼らはHTMLテンプレートエンジンの速度に出くわしましたが、それはそれを「分散」する方法がすぐにはわかりません。 サブパターンのキャッシュによって何かを絞り出すことができますが、肯定的な結果が得られたにもかかわらず、テンプレートエンジンの作業時間は依然としてページ生成の速度の基礎となりました。 おそらく他のテンプレートエンジンでさえ、より根本的な対策が必要でした...



最速のテンプレートエンジンの聖杯を見つけるという困難なタスクにおけるイニシアチブの1つの歴史については 、この問題の解決に関与したDmitry Karasikによる詳細レポートで以下をお読みください。



「私の意見では、誰もがWeb開発にテンプレートエンジンを使用しています。 誰もが選択したツールの不完全さを使用し、ゆっくりと誓います。 結局のところ、ブランチプロジェクトの別のテンプレートエンジンへの移行は非常に困難な問題であるため、多くの場合、多くのコードを未知の結果で書き直すよりも、既存のパッケージで何かを終了する方が好まれます。



レジストラREG.RUは、 テンプレート::ツールキットで記述されたWebサイトの速度を上げる必要に直面し、この問題を解決するように指示しました。 考えられるソリューションを分析した社内の人々が、 Project :: Toolkit（以降TT）の完全な構文を維持しながら、プロジェクトを別のテンプレートエンジンText :: Xslateに移行することに決めたのは嬉しい驚きでした。



Xslateについて聞いたことがありますが、以前は取引していませんでした。 ウェブサイトに記載されている広告データによると、彼はTTを158回追い抜いており、「彼が言ったことの少なくとも半分が正しい」場合（c）、これは優れた選択肢のように見えます。 そのため、疑う余地はほとんどありませんでした。ほとんどのプロジェクトはCで書かれており、少なくとも真珠自体よりも高速でした。 さらに、XslateはTT構文を部分的にサポートしています。 コードを見ると、すべてが「OK」であるように思われました-おそらく著者がテンプレートエンジンに焦点を当てていたため、この方向にXslateを拡張することに興味がある人には基本的なヒントを残したため、完全なサポートはありません（プロジェクトに参加するための一種の招待）。 これはすべて非常に有望に見えたので、Xslateを終了してTTを完全にサポートするか、顧客にとって十分にサポートするまで決めました。REG.RUと私は喜んで同意しました。 すべてが勝者であるように見えました-クライアントは158倍速くコードを受け取り、Xslateは改善された構文と新しいユーザーを受け取り、コミュニティはTT2に代わる優れた代替手段を受け取ります。



問題はすぐに始まりました。 Xslate Goro Fujiの著者（alas、alas）は、手紙にもIRCにも答えませんでした。 著者の意図と最も一致するようにモジュールを拡張する方法に同意するという私の提案は、実際には失敗しました。 たぶん私の手紙は日本のエチケットのルールに従って編集されていなかったのでしょう。 たまたま会議で日本のプログラマーに会ったことがありますが、電話での笑顔や「こんにちは」よりも活発に連絡を取ることができなければ、おそらくオンラインはさらに難しいでしょう。



結局のところ、RTFSマントラは決して失敗していません。 コードが高品質であれば、作成者が共同作業を望まない場合でも、パッチまたは分岐プロジェクトをいつでも公開できます。 最後に、Xslateをプロジェクトとして開発する方法を理解するふりはしませんが、ベースとして高度に最適化されたエンジンのみを使用するつもりです。



そして、私はモジュールの勉強を始めました。 公平に言えば、コードとXslateアーキテクチャの両方が優れていると言う価値があります。 学生はそれらを研究する必要があり、経験のあるプログラマも見た目が良いでしょう。 Xslateは、テンプレートエンジンが基本的にテキストのチャンクを往復するという事実に基づいて構築されており、最適化はすでにそのレベルで開始されています-通常のパールオオムギの連結を置き換える

  $ a。= $ b 

Cで書き換えられたものは同じアナログですが、可能な限り軽量です。 また、すべての処理もCで行われます。テンプレートエンジンのアトミック操作（たとえば、上記の連結または[％IF％]、[％CALL％]などのTTに関する操作）は、Cだけでなく、テンプレートファイルのループサイクルが書き込まれます。 これは、（Cで書かれていても）真珠から手順を呼び出すのに必要なクロックサイクルが節約されたことを意味します-これは非常に高価な操作です。 たとえば、TTで書かれたような非常に一般的なテンプレートは

 [％IF a％]
   テキスト
 [％ELSE％]
   テキストb
 [％END％] 

Xslateは、次の形式の疑似アセンブラーコマンドに変換します。

 .if a
 .literal "text a"
 .print＃1
 .goto 3
 .literal "text b"
 .print＃2
 .end

バイナリコンパイル済みファイルに。 テンプレートもコンパイルしますが、次のようなパールコードに変換するTTとは異なります。

テンプレート::ドキュメント->新規（ 
    ブロック=> sub {
         ...
         eval {
             ...
             if（$ a）{
                $ output。= "text a";
             } else {
                $ output。= "text b";
             }
             ...
         }
     }
 ）
 ...

そして、通常のevalをロードします。

しかし、このXslate作成者でさえ十分に考えていませんでした！ 個々の「アセンブラ」コマンドを実行するコードは、考えられるように作成されていません。たとえば、（概略的に）：

 for（i = 0; i <opcodes.length; i ++）{
     opcodes.list [i] .callback（）;
 }

いわゆる 縫製コード ：

     LABEL（noop）：TXCODE_noop（aTHX_ st）;  goto *（st-> pc-> exec_code）;
     LABEL（move_to_sb）：TXCODE_move_to_sb（aTHX_ st）;  goto *（st-> pc-> exec_code）;
     LABEL（move_from_sb）：TXCODE_move_from_sb（aTHX_ st）;  goto *（st-> pc-> exec_code）;
     LABEL（save_to_lvar）：TXCODE_save_to_lvar（aTHX_ st）;  goto *（st-> pc-> exec_code）;
     ...
     LABEL（終了）：TXCODE_end（aTHX_ st）;

実行は、オペコードの「終了」に到達するまでgoto間で「ジャンプ」します。 実際、たとえばTXCODE_move_to_sbコードがregister.a = register.bのように見える場合、不要な関数呼び出しはまったくありません。これにより、プロセッサボディ全体が理論的にプロセッサキャッシュに収まるようになります（これは、テンプレートが単純なアクション-常に真珠機能の呼び出しが必要です）。



パーサーの側から見ると、すべてが面白そうに見えました。 個人的には、構文解析の仕組みがあり、これらのLL / LR / LALRパーサーは特に興味深いものではありませんでしたが、そのアイデアを評価することができます。 TTとXslateはどちらも小さな独立した言語であり、単なるディレクティブのセットではありません（たとえば、Xslateでは、次のように「ゴルフ」できます：

 こんにちは、<：$ lang // "Perl"：> world！ 

ただし、TTは、Parse :: Yappによって実行された古い実績のあるlex / yaccメソッドを使用しました。 Xslateは、 トップダウンパーサーのように作られた独自のパーサーを使用しました。 ここでは詳しく説明しませんが、このタイプのパーサーを使用して構文を拡張することは、私の経験から見て最も楽しいタスクとはほど遠いというだけです。 ほとんどの場合、コードの多くの部分がXslateでサポートされているすべての構文に共通しており、それぞれを部分に分解する必要がありました。



ただし、実行時の最大の問題はまだ発生していませんでした。 判明したように、ランタイムのXslateには、TTの[％CALL％]に似たメカニズムがなく、別のテンプレートで定義された関数を呼び出すことができます。 これで対処方法を見つけ、数週間の自由時間を使って擬似アセンブラーを選び、その原理を理解しようとして、突然何かが壊れないようにしました。 また、TTには[％-...％]などの非対称ブラケットを使用する機能があり、Xslateパーサーはその方法を知らないことも判明しました。 しかし、最大の障害は、TTとXslateが変数のスコープ可視性がまったく異なることです。 TTで[％foo = 'bar'％]と書き、その後変数fooがすべてのサブパターンで見える場合、Xslateではローカル変数です。



もちろん、これらの問題はすべて解決できましたが、努力と結果のバランスから疑問が生じました。プロジェクトのパイロット評価には、このような規模の変更は含まれませんでした。 顧客との会議の後、会社は少なくとも2倍のパフォーマンスの向上に関心があることが判明しました。 そして、生産性を向上させることが実際に可能であることを評価することにしました。おおまかに言って、「ろうそくに値するゲームです」。



これにより、すべてがシンプルになりました-優れたプロファイラーであるDevel :: NYTProf（特にDevel :: DProfでの長年の経験後）は、テンプレートをトレースするときにこのような興味深い画像を生成しました。







表は再び5倍長くなり、明確にするためにいくつかの行を削除しましたが、大まかな分析でさえ、主な負荷はTTのせいではなく、TTのせいで発生することを示唆しています。 その結果、TTをXslateに置き換える速度がゼロであることを確認したとしても、望みの2倍の増加は得られません。 それにもかかわらず、完全に手ぶらで後退しないようにするために、私は探し回ることに決めました、そして、これは私が見つけたものです：



•main_menu.incとindex.htmlで、次のような気味の悪い遅いコードを見つけました

 [％FOR x％]
 [％for y％]
 ...何かをする...
 [％END％]
 [％END％]

これは簡単に高速のものに対応します。 これだけでも、必要に応じて速度を2倍にすることはすでに可能だと思います。



•その後-テンプレート:: Stash、TTの一部。 この主な容疑者は長い間しっかりと最適化されており、テンプレート:: Stash :: XSに他に行く場所はありません-明らかに、かつてその速度は誰かに干渉していました。 それにも関わらず、問題となったのはパールオオムギの部分であり、私は少し削減しましたが、356msから238msに低下しました。 唯一の問題は、この「カット」がこの顧客専用に機能し、この特定のプロファイルで機能することです。一般的な使用のためのパッチは意味がありません。 言い換えれば、ローカルハックをどのように適用できるか、しかしシステム管理者は毎回それを課す必要があります。 一般的に、疑わしい利点が得られます。 誰が気にしますか、ここにあります：

 --- Template-Toolkit-2.24 / xs / Stash.xs.0 2012-11-22 23:26：54.670467300 +0100
 +++ Template-Toolkit-2.24 / xs / Stash.xs 2012-11-22 23:26：39.406594300 +0100
 @@ -1198.21 +1198.7 @@
      }
 
      if（！SvOK（RETVAL））{
 -dSP;
 -ENTER;
 -SAVETMPS;
 -プッシュマーク（SP）;
 -XPUSH（ルート）;
 -XPUSH（ident）;
 -PUTBACK;
 -n = call_method（ "undefined"、G_SCALAR）;
 -スペイン;
 -if（n！= 1）
 -croak（ "undefined（）は単一の値を返しませんでした\ n"）;
 -RETVAL = SvREFCNT_inc（POP）;
 -PUTBACK;
 -FREETMPS;
 -立ち去る;
 + RETVAL = newSVpv（ ""、0）;
      }
     他に

大まかに言うと、undefinedの呼び出しは高コストですが、空の文字列を返すだけで済みます。 しかし、それが6万回の呼び出しになると、それに応じて費やされる時間が長くなります。



•IO :: Uncompress :: *およびIO :: Compress :: *は、判明したとおり、memcachedに関連しています-サイズがデフォルトのメガバイトを超える場合、データを圧縮します。 このオプションを試してみましたが、改善は微視的でした。



•最後に、Template :: Iterator、180,660呼び出し。 部分的にXSにコピーし、263から7ミリ秒に減らしました。これは、リクエスト全体の5〜7％です。 結果はTemplate :: Iterator :: XSとしてCPANにアップロードされました。 これは、コミュニティに利益をもたらすことができる唯一のものです。 TTに既存のプロジェクトがある場合は、このモジュールを非常にうまく構築できます。

テンプレートを使用します。
テンプレートを使用::イテレータ:: XS;
 $テンプレート::構成:: ITERATOR = 'テンプレート::イテレーター:: XS';

そしてそれが何をもたらすかを見てください



結果は自慢できないほどでした。 TTから他の何かに切り替えるのがどのくらい最適か（そしてそれが価値があるかどうか）の問題は、これまでのところ私には未解決のままです。 さらに、TTが非常に悪いという明確な結論を出すことは不可能です-いずれにせよ、実行速度に関しては、これはむしろ一般的な議論の問題です。



最後に、興味深いコードを掘り下げる機会と、テンプレート::イテレータ:: XSモジュールの公開の永続性について、REG.RUに感謝します。この記事の結果は、私のイニシアチブではリリースされそうにありませんでした。 通常、企業は、注文どおりに作成されたコードをどこにでも公開することに率直に関心を持ちません。 この点で、REG.RUは快い例外であり、パールコミュニティを代表して、私は感謝しています。