Generic O/R mapper - performance hacks

1. Introduction

The OR mapper basically is implemented for best performance, but due to bad design of the data model sometimes, performance hacks could be necessary. The following chapter describes examples, where manual interaction into the mapper layer or the usage of the mapper has good impact on the performance.

2. Performance hacks

2.1. Requests with attributes

In case of frequent table access via attributes in WHERE clauses it could be helpful to add an index to the relevant columns.

2.2. Creation of the mapper

If there is no reason why, the mapper should be created in SESSIONSINGLETON mode. This brings the advantage, that the mapping and relation table is parsed only one time within a session. This activity gains the performance up to 10% on every further call of the application. The following lines of code show how to create the mapper in SESSIONSINGLETON mode:
PHP code
// get the mapper factory $ormFact = &$this->getServiceObject( 'modules::genericormapper::data', 'GenericORMapperFactory', APFService::SERVICE_TYPE_SESSION_SINGLETON // <-- Indicates SESSIONSINGLETON mode ); // create the mapper $orm = &$ormFact->getGenericORMapper( {CONFIG_NAMESPACE}, {CONFIG_NAME_AFFIX}, {CONNECTION_NAME}[, $logStatements = false] );

2.3. JOIN optimization

If you have a huge amount of data and you often have to query complex object relations, it is recommended to write the JOIN conditions within the statements yourself. Thereby, you can take care, that the JOIN conditions, that are more selective are placed in the front of not-so-selective conditions. This method can positively influence the execution time.


Do you want to add a comment to the article above, or do you want to post additional hints? So please click here. Comments already posted can be found below.
There are no comments belonging to this article.