47

私は最近Hamlで遊んでいて、結果のコードが私に見える方法が本当に好きです...開発者。また、デザイナーがそれを消費したり変更したりできることについてもあまり心配していません...私たちは小さなチームです。

そうは言っても、私たちが信じるプロジェクトの作業を開始すると、かなりのトラフィックが発生します(誰が発生しませんか?)。hamlについて知らないことがあるのではないかと心配しています。hamlではできないerbでできることはありますか?プロジェクトが成長するにつれて、hamlは悪影響を及ぼしますか?他に考慮すべきことはありますか?

そして最後に...Hamlはどのようにスピード的にerubisと比較されますか?おそらく今はerbとerubyを打ち負かしているようです...

ありがとう!

4

7 に答える 7

45

ハムルが揺れる。最近のパフォーマンスの数値は見ていませんが、最近は erb にかなり近いです。醜いモードをオンにすると(きれいなインデントを防ぎます)、erbよりも高速になる可能性があると思います。Hamlで1日280万ページビューを実行しています。

Haml ソース ツリーにチェックインされたベンチマーク ツールがあります: http://github.com/nex3/haml/tree/master/test

2009 年 11 月の更新

Nathan (Haml の主な開発者)は、ブログでいくつかの Haml 2.2 ベンチマークを公開しました。そこに正確な数字が表示されますが、要するに:

  • 通常(きれいな印刷)モード = ERB の 2.8 倍遅い
  • 醜いモード (きれいなタブは追加されていません) = ERB と同じ

Haml::Template::options[:ugly] = trueイニシャライザまたは環境ファイルに配置することで、醜いモードを有効にすることができます。醜いモードは実際にはそれほど醜いわけではないことに注意してください。結果として得られる HTML は、実際には ERB よりもはるかにきれいです。単に適切にインデントされていないだけです。

于 2008-09-19T01:18:57.887 に答える
27

Railsを使用する場合、Hamlとerubisのパフォーマンスの違いはごくわずかです。いずれにせよ、テンプレートは最初のヒット後にコンパイルおよびキャッシュされます。これをフラグメントおよびページのキャッシュと組み合わせると、ビューがアプリケーションのパフォーマンスのボトルネックではないので安心できます。

あなたが自分自身に問うべき質問は、Hamlを書くのが好きですか?それはあなたをより生産的にしますか?そうすれば、簡単に決めることができます。

于 2008-09-18T23:05:11.813 に答える
11

HAML は構造化された HTML を簡単に記述できる優れたツールであり、一般的に使用するのが楽しいため、私は HAML が大好きです。しかし、サイトのトラフィック量に基づいてツールを選択することとはほとんど関係がありません.

トラフィックが心配な場合は、キャッシュを適切に使用することを心配する必要があります。次に、一般的な Web アプリケーションのパフォーマンスの原則を適用する必要があります。その結果、ページの読み込みに対して非常に迅速な応答が得られます。これは、トラフィックの多い Web サイトが本当に必要としているものです。

Web サイトのパフォーマンスを改善する方法を示すいくつかのプレゼンテーションがここにあります。

Railsキャッシングを適切に使用する方法を学ぶのに私が知っている最良の場所は次のとおりです。

于 2008-12-22T21:26:57.337 に答える
4

それは完全に個人の好みと保守性の問題だと思います。私にとって、Haml はテンプレートを読みやすく、理解しやすくし、パフォーマンスは非常に満足のいくものです。最終的に、テンプレート言語は、最適化が必要な場所になる可能性は低いです。データベース クエリ、ビューまたはオブジェクトのキャッシュなどを最適化する可能性が高くなります。

ただし、ERb テンプレートの場合、erubis を使用すると、基本的に無料でパフォーマンスが向上します。

于 2008-09-18T22:22:42.197 に答える
2

コーディングの観点からhamlがどのように機能するかが気に入った場合は、テンプレートエンジンのパフォーマンスについてあまり心配する必要はありません。(ただし、ご指摘のとおり、現在は高速です。)他のエンジンが生成できる出力を確実に生成できます。

一般に、パフォーマンスの問題が発生しているテンプレートエンジンについて心配するよりも、キャッシュの設定にエネルギーを投入する方が有益です。

于 2008-09-19T01:32:11.600 に答える
1

個人的には、コンパイル済みのテンプレートで erubis を使用することをお勧めします。

特に動的テンプレートが必要ない場合。そうすれば、最大の速度低下は、Ruby が Ruby を解析できる速度によって制限されます。

私はおそらく、変更されたソース テンプレートを監視し、使用していないときにオフにできる変更時に自動コンパイルする小さな cron ジョブをセットアップするでしょう。

一度コンパイルして、何度も使用してください。

ああ、本当に速度が気になるなら、天神も一見の価値があるかもしれません (erubis と同じクリエイター)

http://www.kuwata-lab.com/tenjin/rbtenjin-examples.html

于 2008-09-18T19:37:41.077 に答える
0

ええと、Hamlのパフォーマンスはリリースごとに向上し続けています。現時点で許容できる場所にありますか?それはあなたが決めることです(私は「はい」と言う傾向がありますが、それはあなたのニーズに基づいたあなたの選択です)。テンプレートとそれらが提供する読みやすさが気に入った場合は、パフォーマンスの低下(ただし無視できる程度)が実際に決定の最終的な要因になるはずです。

Hamlと組み合わせて使用​​することを検討する必要がある他のツールの1つは、make_resourcefulです。これは、RailsアプリのRESTfulな機能の多くを簡素化するHamlのメンテナー(Nathan Weizenbaum)によるもう1つの宝石です。

Haml(およびm_r)についてさらに具体的な質問がある場合は、Nathanが喜んで回答してくれると確信しています。彼には、Jabber/XMPPおよび電子メールで連絡できます。彼の連絡先情報はここにあります。

于 2008-09-19T01:26:56.137 に答える