性能和设计，理论上也是质量的一部分，但之前已经分析过了，这里不再复述，
请参见： http://httl.github.com第2章和第3章。
先来看看静态代码的分析：
1. 单元测试
单元测试覆盖率: (分析工具EclEmma)
HTTL对所有语法，指令，函数，都有相应模板进行测试，参见：
https://github.com/httl/httl/tree/master/src/test/resources/comment/templates
2. FindBugs检测
已通过FindBugs最新版本(2.0.2)检测，零发现。参见FindBugs能发现的问题： http://findbugs.sourceforge.net/bugDescriptions.html
3. JDepend检测
已通过JDepend检测检测，无环依赖，稳定度与抽象度比正常，参见4.1.3分包设计章节。
我们再来看看运行时的稳定性分析：
4. 稳定性测试
在长时间重复运行所有单元测试后，CPU保持平稳：(分析工具JVisualVM)
内存也保持平稳，以YoungGC为主：
虽然HTTL大量使用字节码生成以提升性能，但因为有全量缓存，Perm区也是稳定的：
因设置的内存只有500M，而常规已占400多M，在OLD区几乎快满情况下，也只发生3次FullGC：(分析工具jstat)
从下面Dump后的数据可以看出，JDK编译占用了171M内存，如果开启-Xlint:unchecked编译参数会更大。
如果你觉得JdkCompiler内存占用过多，也可以通过配置换成Javassist编译。(分析工具jmap + MAT)
5. Profile分析
5.1 CPU分析
测试用例为长时间跑模板渲染过程，因解析后有缓存，所以CPU几乎全耗在渲染过程，
解析过程占比较小，符合预期：(分析工具JProfiler)
因同时测试了Writer和OutputStream两种场景，所以上图中各分一半。
展开其中一个渲染过程，各模板比较均匀，占比都不大，没有出现绝对热点，符合预期：
从上图可以看上，相对而言，xml.httl和include_withfilter.httl较慢，展开如下：
可以看出，主要消耗在xstream的parseXml解析和filter的escapseXml转义上。
XML的解析和处理本身就很耗时，在可接受范围内，并且不是核心组件。
长时间运行后，因样本少，xstream解析数据被缓存，所以时间都集中到了escapseXml的charAt上。
注意，上面的图中，浅红色表示当前方法消耗，深红色表示子函数消耗总和。
即然占比如此大，我们来看下代码：
首先String.charAt只是一个char[]下标取值，已经足够简单，不存在性能问题：
public char charAt(int index) {
if ((index < 0) || (index >= count))
throw new StringIndexOutOfBoundsException(index);
return value[index + offset];
}
那再来看看HTTL的escapseXml：
public static String escapeXml(String value) {
if (value == null || value.length() == 0) {
return value;
}
int len = value.length();
StringBuilder buf = null;
for (int i = 0; i < len; i ++) {
char ch = value.charAt(i);
switch (ch) {
case '&':
if (buf == null) {
buf = new StringBuilder(len * 2);
if(i > 0) {
buf.append(value.substring(0, i));
}
}
buf.append("&");
break;
case '<':
if (buf == null) {
buf = new StringBuilder(len * 2);
if(i > 0) {
buf.append(value.substring(0, i));
}
}
buf.append("<");
break;
case '>':
if (buf == null) {
buf = new StringBuilder(len * 2);
if(i > 0) {
buf.append(value.substring(0, i));
}
}
buf.append(">");
break;
case '\"':
if (buf == null) {
buf = new StringBuilder(len * 2);
if(i > 0) {
buf.append(value.substring(0, i));
}
}
buf.append(""");
break;
case '\'':
if (buf == null) {
buf = new StringBuilder(len * 2);
if(i > 0) {
buf.append(value.substring(0, i));
}
}
buf.append("'");
break;
default:
if (buf != null) {
buf.append(ch);
}
break;
}
}
if (buf != null) {
return buf.toString();
}
return value;
}
从代码中可以看出escapseXml已经做了一些优化：
* 在没有发现特殊符前，不创建StringBuilder对象。
* 在发现第一个特殊符时，将将之前的内容，一次性拷到StringBuilder中。
* StringBuilder对象以两倍长度创建，防止扩容带来数据迁移。
* 通过switch每字符，以最短路径分发处理逻辑。
因escapseXml在没有发现特殊符时，只是通过charAt遍历字符串，不会做其它动作，所以长时间运行后，会显得charAt比较热，要过滤至少要遍历一遍，这已经是最低复杂度，所以并不是什么问题。
在压测Apache开源commons-lang中的StringEscapeUtils中的escapeXml后，发现性能甚至不如HTTL的实现。
那也看下commons-lang的StringEscapeUtils源代码：(注释中有说明它慢的原因)
public static String escapeXml(String str) {
if (str == null) {
return null;
}
return Entities.XML.escape(str);
}
public String escape(String str) {
// 这里总是创建StringWriter，如果str没有特殊符，这样首先会浪费创建Writer对象的成本。
// 其次浪费将一个个字符写到writer中，再toString回来的大量性能，而且没有特殊符是大概率事件。
// HTTL在没有特殊符时是直接返回原始串的，不创建任何对象，不做任何来回拷贝。
// 另外，StringWriter里面封装的StringBuffer，它的所有方法是带同步锁的，而HTTL采用无锁的StringBuilder。
StringWriter stringWriter = createStringWriter(str);
try {
this.escape(stringWriter, str);
} catch (IOException e) {
throw new UnhandledException(e);
}
return stringWriter.toString();
}
public void escape(Writer writer, String str) throws IOException {
int len = str.length();
for (int i = 0; i < len; i++) {
char c = str.charAt(i);
// 这里使用map的hash查找实体的名称，比HTTL的switch慢。
String entityName = this.entityName(c);
if (entityName == null) {
if (c > 0x7F) {
writer.write("&#");
writer.write(Integer.toString(c, 10));
writer.write(';');
} else {
writer.write(c);
}
} else {
writer.write('&');
writer.write(entityName);
writer.write(';');
}
}
}
当然，如果你有更好的实现，欢迎提供，非常感谢。
你可以通过配置切换实现：
value.filters=com.your.YourEscapeXmlFilter
5.2 内存分析
内存中以char[]和String最多，因为模板本身是大量文本处理，符合预期：(分析工具JProfiler)
过滤HTTL自身的类，因Context为会话域模型，每次执行都会创建Context，所以Context类最多，它比较轻量，符合预期：
长时间运行后，Context等实例数保持稳定，并没有爆炸式增长，表示可有效回收，符合预期：
