Spring/spring-data-neo4j
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

documentation updates

Browse Source
This commit is contained in:
Michael Hunger
2011-03-18 15:13:49 +01:00
parent 6a83302e62
commit 7da8051333
2 changed files with 36 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
src/docbkx/index.xml
View File

@@ -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>

29
src/docbkx/reference/performance.xml
View File

@@ -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>