Generic O/R mapper - performance hacks
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.
In case of frequent table access via attributes in WHERE clauses it could be helpful to add an index
to the relevant columns.
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]
);
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.