From ff9d2fd068c66272c2af959efbeb8849e8e1c6a0 Mon Sep 17 00:00:00 2001 From: Nathan Marz Date: Thu, 8 Sep 2016 08:03:25 -0400 Subject: [PATCH] Updated Specter's inline caching implementation (markdown) --- Specter's-inline-caching-implementation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Specter's-inline-caching-implementation.md b/Specter's-inline-caching-implementation.md index 5573d5e..ce5c9f5 100644 --- a/Specter's-inline-caching-implementation.md +++ b/Specter's-inline-caching-implementation.md @@ -40,7 +40,7 @@ With all the ins and outs of doing inline caching now being understood, it turns The goal of inline caching is to do as much work ahead of time so the work to finish compilation at runtime (like parameterizing with local variables) is extremely fast. The prior design reduced the runtime work to a single operation: creating an array and filling it with dynamic params. However, "one runtime operation" is not a hard constraint. It's fine to have more operations as long as they are all fast. -The end result of compilation is a single object implementing the `RichNavigator` interface that encapsulates all the navigation done by the path. With new new inline caching implementation, the `foo` example from before compiles to this: +The end result of compilation is a single object implementing the `RichNavigator` interface that encapsulates all the navigation done by the path. With the new inline caching implementation, the `foo` example from before compiles to this: ```clojure (defn foo [a data]