1

私のdjangoアプリケーションには、doctype、script、cssタグなどの典型的なベーステンプレートがありました。

明確さとコード編成のために、この基本テンプレートを構成部分に分解し、各部分が前の部分を拡張して、特定のものを1つだけ追加しました。例：base / favicon.html：

{% extends "base/chromeframe.html" %}
{% load staticlink %}

{% block metatags %}{{ block.super }}
<link href="{% staticlink 'img/favicon.ico' %}" rel="shortcut icon" type="image/x-icon">{% endblock metatags %}

base / chromeframe.htmlを拡張します：

{% extends "base/mobile.html" %}

{% block metatags %}{{ block.super }}{% if 'chromeframe' in request.META.HTTP_USER_AGENT %}
<meta http-equiv="X-UA-Compatible" content="chrome=1">{% endif %}{% endblock metatags %}

これにより、ベーステンプレートがより管理しやすくなります。 このアプローチに対して大きなパフォーマンスペナルティを支払っていますか？ テンプレートレンダリングのベンチマークを行うための良い方法は何ですか？

継承ではなくインクルードを使用することを提案する前に、ベーステンプレートから派生したページによってオーバーライドされるブロックを設定しているため、これは機能しません。

これらのテンプレートパーツのある種の事前コンパイルを設定できることは承知しています。

4

2 に答える 2

4

テンプレートの実行時間がページの読み込み時間の重要な要因であることに気づいたことはありません。非常にトラフィックの多いサイトを実行している場合を除いて、それを心配することはおそらく時期尚早の最適化の領域にあります。

ほとんどの場合、実行速度をわずかに上げるのではなく、開発と保守を容易にするためにコードを最適化するのが最も効果的です。

ただし、所要時間を確認したい場合は、プロファイリングのDjangoページを確認してください。

于 2013-03-01T19:22:56.197 に答える
3

従来の知識を確認しました。22層の「不要な」継承があっても、レンダリング時間の差はわずかです。

私のテスト：

import time

from django.core.management.base import BaseCommand
from django.shortcuts import render_to_response as r2r

ITTER=100

class Command(BaseCommand):
    def handle(self, *args, **options):
        start = time.clock()
        for i in range(ITTER):
            r2r('base.html', { 'i': i },)
        middle = time.clock()
        for i in range(ITTER):
            r2r('newbase.html', { 'i': i },)
        end = time.clock()
        print "old way:%f new way:%f" % (middle-start, end-middle)

ベーステンプレートフラグメントをnewbase.htmlに丹念に再統合して、パフォーマンスのわずかな改善のみを見つけました。

古い方法：1.770000新しい方法：1.460000

それでもパフォーマンスは大幅に向上しますが、結果として生じる読み取り不可能な混乱であるnewbase.htmlを正当化するほど重要ではありません。

他の場所で最適化を探します。

于 2013-03-01T21:24:42.777 に答える