Added performance graph

README.rst

@@ -280,7 +280,15 @@ the letter ``b`` repeated 100 times.  If we increase that number to 300, the
 parser will actually exhaust the available heap space in the default JVM
 configuration.
 
-With that said, there are very few grammar/input combinations which push the
+The actual performance on the ``s`` grammar is demonstrated by the following
+graph (plotted on a cubic scale).  The gray line is *y = kx^3* (for some constant
+*k*).  The blue line was determined emperically from progressively longer runs
+(starting at strings of length 10 and increasing to length 100) on the ``s``
+parser shown above.  The *y* axis represents time in milliseconds.
+
+.. image:: performance.jpg
+
+With all this said, there are very few grammar/input combinations which push the
 framework to its limit.  In fact, for grammars which are LL(1)_, the GLL Combinators
 framework should actually be *faster* than traditional parser combinators.  For
 example::

buildfile

@@ -27,8 +27,12 @@ define 'gll-combinators' do
       file.puts latex
     end
   end
+
+  file 'target/performance.jpg' => ['performance.jpg'] do |f|
+    cp 'performance.jpg', f.to_s
+  end
 
-  pdf = file 'target/readme.pdf' => [file('target/doc/readme.tex')] do |f|
+  pdf = file 'target/readme.pdf' => [file('target/doc/readme.tex'), file('target/performance.jpg')] do |f|
     info 'Compiling readme.tex into PDF'
     Dir.chdir _(:target, :doc) do
       `latex readme`
@@ -38,7 +42,7 @@ define 'gll-combinators' do
     end
   end
 
-  html = file 'target/readme.html' => ['README.rst'] do |f|
+  html = file 'target/readme.html' => ['README.rst', file('target/performance.jpg')] do |f|
     info 'Generating readme.html'
     mkdir File.dirname(f.to_s) unless File.exists? File.dirname(f.to_s)