diff --git a/src/docbkx/index.xml b/src/docbkx/index.xml
index 036e7f31b..906cf69f6 100644
--- a/src/docbkx/index.xml
+++ b/src/docbkx/index.xml
@@ -41,7 +41,7 @@
         <xi:include href="tutorial/recommendations.xml"/>
     </part>
 
-    <part id="reference">
+
         <title>Reference</title>
         <partintro>
             <para>
@@ -56,12 +56,12 @@
         <xi:include href="reference/setup.xml"/>
         <xi:include href="reference/cross-store.xml"/>
         <xi:include href="reference/samples.xml"/>
-        <!--<xi:include href="reference/performance.xml" />-->
-        <!--<xi:include href="reference/template.xml" />-->
-        <!--<xi:include href="reference/annotations.xml" />-->
-        <!--<xi:include href="reference/aspectj-intro.xml" />-->
-        <!--<xi:include href="reference/neo4j-intro.xml" />-->
-        <!--<xi:include href="reference/spring-data.xml" />-->
-        <!--<xi:include href="reference/neo4j-server.xml" />-->
-    </part>
+        <xi:include href="reference/performance.xml" />
+        <xi:include href="reference/template.xml" />
+        <xi:include href="reference/annotations.xml" />
+        <xi:include href="reference/aspectj-intro.xml" />
+        <xi:include href="reference/neo4j-intro.xml" />
+        <xi:include href="reference/spring-data.xml" />
+        <xi:include href="reference/neo4j-server.xml" />
+
 </book>
diff --git a/src/docbkx/reference/performance.xml b/src/docbkx/reference/performance.xml
index e1832cfd9..5bfa652d6 100644
--- a/src/docbkx/reference/performance.xml
+++ b/src/docbkx/reference/performance.xml
@@ -3,12 +3,37 @@
 <chapter id="reference_performance">
     <title>Performance considerations</title>
     <para>
-        ...
+        Although adding another layer of abstraction is always the solution to look for in software development,
+        each of those layers adds overhead and performance penalties. This chapter discusses the performance
+        implications of using Spring Data Graph on top of the native Neo4j API.
     </para>
     <section>
         <title>When to use SDG?</title>
         <para>
-            ...
+            The focus of Spring Data Graph is to add a convenience layer on top of the native Neo4j API. This should
+            enable developers to get up and running with the graph database very quickly, having their domain objects
+            mapped to the graph. Building on this foundation one can later explore other, more efficient ways to
+            explore and process the graph - if the performance requirements demand it.
+        </para>
+        <para>
+            Like any other object mapping framework, the domain entities that are created, read or persisted represent
+            only a small fraction of the data stored in the database. This is the set needed for a certain use-case to
+            be displayed, edited or processed in a low throughput fashion. The main advantages of using an object mapper
+            in this case is the ease of use of real domain objects in your business logic and also with existing
+            frameworks and libraries that expect Java POJOs as input or create them as results.
+        </para>
+        <para>
+            Spring Data Graph was not designed with a major performance focus. It adds some overhead to pure graph operations.
+            Something to keep in mind is, that the access of properties and relationships is a read trough in the attached
+            case. So to avoid multiple read-throughs it is sensible to store the result in a local variable at the scope of
+            use (method, class or jsp for example).
+        </para>
+        <para>
+            Most of the overhead comes from the use of the Java Reflection API, which is leveraged to provide information about Annotations, Fields and Constructors.
+            Some of the information is already cached by the JVM and the library, so that only the first access gets a
+            performance penalty.
+        </para>
+        <para>
         </para>
     </section>
 </chapter>