Optimization idea that might not be good OO

[Gordon]

I'm using a factory pattern to generate objects, so I can check the
success of the operation in the factory, return the object on success
or return NULL on failure. The objects are abstractions of rows in a
database so a database lookup is done for each object created.

I noticed that running certain scripts could result in the same object
being created in the factory multiple times (ie the same database row
might be used to instantise an object more than once). This gave me
the idea that I could get better performance if I maintained a cache
of objects in the factory, if the requested item hasn't already been
requested then do the DB fetch and instantise as usual, if the item is
already in the cache return a reference to it.

Thinking more about it though, I have a feeling that this might just
be a Singleton pattern in disguise. There's plenty of documentation
out there on why singletons are a bad thing and how they're against
the spirit of OO. But the elimination of object creation overhead is
still quite tempting...

So basically I'm wondering if it's worth trying to implement the
object cache. I can see 3 possibilities:

Leave things as they are
Return references from a cache of items when the same item ID is
requested more than once (Eliminate object creation and DB lookup
overhead but might be a Singleton pattern)
Return clones from a cache of items when the same item ID is requested
more than once (Eliminate DB lookup overhead but still have object
creation overhead).

What would you guys recommend?

[C. (http://symcbean.blogspot.com/)]

On May 23, 1:05 pm, Gordon <[e-mail]:

I'm using a factory pattern to generate objects, so I can check the
success of the operation in the factory, return the object on success
or return NULL on failure. The objects are abstractions of rows in a
database so a database lookup is done for each object created.

I noticed that running certain scripts could result in the same object
being created in the factory multiple times (ie the same database row
might be used to instantise an object more than once). This gave me
the idea that I could get better performance if I maintained a cache
of objects in the factory, if the requested item hasn't already been
requested then do the DB fetch and instantise as usual, if the item is
already in the cache return a reference to it.

Thinking more about it though, I have a feeling that this might just
be a Singleton pattern in disguise. There's plenty of documentation
out there on why singletons are a bad thing and how they're against
the spirit of OO. But the elimination of object creation overhead is
still quite tempting...

So basically I'm wondering if it's worth trying to implement the
object cache. I can see 3 possibilities:

Leave things as they are
Return references from a cache of items when the same item ID is
requested more than once (Eliminate object creation and DB lookup
overhead but might be a Singleton pattern)
Return clones from a cache of items when the same item ID is requested
more than once (Eliminate DB lookup overhead but still have object
creation overhead).

What would you guys recommend?

You're trading performance for code complexity.

If this is a stateless script (web request or message invoked - but
specifically short-lived) and you can determine a mapping without
going back to the database, then I'd say don't use a cache - keep a
array, indexed on the map, of all the factories progeny. This is a
much simpler proposal than a cache where you need to keep making space
for new objects once it fills.

C.

[Michael Fesser]

..oO(Gordon)

>I'm using a factory pattern to generate objects, so I can check the
success of the operation in the factory, return the object on success
or return NULL on failure. The objects are abstractions of rows in a
database so a database lookup is done for each object created.

I noticed that running certain scripts could result in the same object
being created in the factory multiple times (ie the same database row
might be used to instantise an object more than once). This gave me
the idea that I could get better performance if I maintained a cache
of objects in the factory, if the requested item hasn't already been
requested then do the DB fetch and instantise as usual, if the item is
already in the cache return a reference to it.

Thinking more about it though, I have a feeling that this might just
be a Singleton pattern in disguise. There's plenty of documentation
out there on why singletons are a bad thing and how they're against
the spirit of OO. But the elimination of object creation overhead is
still quite tempting...

Singletons are perfectly fine in many situations.

There's never a wrong tool, just wrong usage.

>So basically I'm wondering if it's worth trying to implement the
object cache. I can see 3 possibilities:

Leave things as they are
Return references from a cache of items when the same item ID is
requested more than once (Eliminate object creation and DB lookup
overhead but might be a Singleton pattern)

You don't need references here. PHP will handle that quite well on its
own (I assume we're talking about PHP 5 here, PHP 4 wouldn't make sense
anymore).

>Return clones from a cache of items when the same item ID is requested
more than once (Eliminate DB lookup overhead but still have object
creation overhead).

What would you guys recommend?

Let the factory create the instance if it doesn't exist yet and simply
return it without any explicit reference. The next time just return the
same object again. That's it.

Keep one thing in mind: If the object is modified somewhere "outside"
the factory, it will also affect the one "inside" the factory, because
internally it's always the same object. In such cases you might want to
clone the object, but only if really necessary.

Micha

[Dikkie Dik]

Gordon wrote:

I'm using a factory pattern to generate objects, so I can check the
success of the operation in the factory, return the object on success
or return NULL on failure. The objects are abstractions of rows in a
database so a database lookup is done for each object created.

"Return NULL on failure" If it really is a failure (i.e. the record
asked for must exist), you can throw an Exception. If it is normal, ther
is something called a "Null object". This is an object that implements
the default actions that would normally be taken if null was returned.
Such a null object is not applicable in all circumstances, but it is
good to know that such a pattern exists.

Ik have though a lot about database code and some old thoughts (I know I
should update them) can be found at:

http://www.w-p.dds.nl/article/wrtabrec.htm

>
I noticed that running certain scripts could result in the same object
being created in the factory multiple times (ie the same database row
might be used to instantise an object more than once). This gave me
the idea that I could get better performance if I maintained a cache
of objects in the factory, if the requested item hasn't already been
requested then do the DB fetch and instantise as usual, if the item is
already in the cache return a reference to it.

This is called "laziness". I do that for most of my database work.

>
Thinking more about it though, I have a feeling that this might just
be a Singleton pattern in disguise. There's plenty of documentation
out there on why singletons are a bad thing and how they're against
the spirit of OO. But the elimination of object creation overhead is
still quite tempting...

I don't like Singletons at all, but that is a matter of taste. The
difference between a Singleton and an instance held by the Application
object is not that big. I prefer the second, but again this is a matter
of taste. If Singletons get in the way of unit testing, I have an "in
between" pattern to deal with it:

http://www.w-p.dds.nl/pathalfs.php

>
So basically I'm wondering if it's worth trying to implement the
object cache. I can see 3 possibilities:

Leave things as they are
Return references from a cache of items when the same item ID is
requested more than once (Eliminate object creation and DB lookup
overhead but might be a Singleton pattern)
Return clones from a cache of items when the same item ID is requested
more than once (Eliminate DB lookup overhead but still have object
creation overhead).

What would you guys recommend?

I usually prefer the reference variant. As Michael Fesser already said,
references come quite natural to PHP5, so you do not need the reference
operator.

Good luck!

[Rik Wasmus]

On Fri, 23 May 2008 14:19:32 +0200, Michael Fesser <ne*****@gmx.dewrote:

.oO(Gordon)

>I'm using a factory pattern to generate objects, so I can check the
success of the operation in the factory, return the object on success
or return NULL on failure. The objects are abstractions of rows in a
database so a database lookup is done for each object created.

I noticed that running certain scripts could result in the same object
being created in the factory multiple times (ie the same database row
might be used to instantise an object more than once). This gave me
the idea that I could get better performance if I maintained a cache
of objects in the factory, if the requested item hasn't already been
requested then do the DB fetch and instantise as usual, if the item is
already in the cache return a reference to it.

Thinking more about it though, I have a feeling that this might just
be a Singleton pattern in disguise. There's plenty of documentation
out there on why singletons are a bad thing and how they're against
the spirit of OO. But the elimination of object creation overhead is
still quite tempting...

Singletons are perfectly fine in many situations.

There's never a wrong tool, just wrong usage.

>So basically I'm wondering if it's worth trying to implement the
object cache. I can see 3 possibilities:

Leave things as they are
Return references from a cache of items when the same item ID is
requested more than once (Eliminate object creation and DB lookup
overhead but might be a Singleton pattern)

You don't need references here. PHP will handle that quite well on its
own (I assume we're talking about PHP 5 here, PHP 4 wouldn't make sense
anymore).

>Return clones from a cache of items when the same item ID is requested
more than once (Eliminate DB lookup overhead but still have object
creation overhead).

What would you guys recommend?

Let the factory create the instance if it doesn't exist yet and simply
return it without any explicit reference. The next time just return the
same object again. That's it.

Keep one thing in mind: If the object is modified somewhere "outside"
the factory, it will also affect the one "inside" the factory, because
internally it's always the same object. In such cases you might want to
clone the object, but only if really necessary.

Well, actually, that's the reason I employ this kind of 'object maps'
sometimes: the fact that a particular object representing a particular
dataset only has one instance, and an alteration at one point in the code
shouldn't be reversed by another (overwritten, yes, but not unrelated
properties to the specific actions reversed to previous state). It is
something to keep in mind if you don't expect it though :).
--
Rik Wasmus
....spamrun finished