Sync from internal

---

Cache Method objects per template rather than per template evaluation.

In a somewhat artificial benchmark, this sped up evaluation by 35%. The benchmark compiles AutoValueTest.java 100 times, and measures how much time was spent by AutoValueProcessor in template evaluation. AutoValueTest.java has 40 @AutoValue classes, and each of those triggers a separate template evaluation. Previously every one of those created a new Method cache (MethodFinder object). Now only the first one (on each iteration of the benchmark) does.

Compilation runs will rarely have as many as 40 @AutoValue classes, but they have often have several, so there is still some benefit.

According to this benchmark, EscapeVelocity and Apache Velocity now have indistinguishable performance.

Internal change: 245835876

---

Avoid excessive reflection overhead by caching the results of method lookups. On an ad-hoc benchmark this improved template evaluation time by 38%. That means that code generators such as AutoValue that use EscapeVelocity should see a substantial speedup.

Internal change: 244671738

---

If $foo is a Map then Velocity interprets $foo.bar the same as $foo["bar"]. Previously EscapeVelocity interpreted it the same as for other objects, by looking for a getBar() method (or boolean isBar()).

It turns out that autoannotation.vm was depending on the old behaviour, so fix that.

Internal change: 244364373

1 files changed, 0 insertions, 3 deletions

diff --git a/README.md b/README.md
index 0f24bc5..e716ecf 100644
--- a/README.md
+++ b/README.md
@@ -14,9 +14,6 @@ the exact same string that Velocity produces. If not, that is a bug.
 EscapeVelocity has no facilities for HTML escaping and it is not appropriate for producing
 HTML output that might include portions of untrusted input.
 
-<!-- MOE:begin_strip -->
-[TOC]
-<!-- MOE:end_strip -->
 
 ## Motivation