NYCPHP Meetup

[charles at softwareprototypes.com]

Hello Ophir,

instantiation of a class is extremely fast and getting faster.
Basically, you're creating a small marker, an instance "frame", which
points back to the object class, and points to every slot variable in
the heap that's given a value. We're talking fractions of a
microsecond to instantiate an object.

There are different allocation schemes out there and I don't know
which one Zend uses but allocating an object is about as fast as
making a popping a frame onto the stack (making a subroutine call in
assembler.) 

Filling its slots is just as fast. You are sending the object a
message so you already have the object frame and you're setting a
slot value to point to a location in RAM where the value is already
located.

The "for Instance" you gave is a perfect example. How do you think
MySQL keeps track of the rows? Each table is an object which defines
each row and each row is an object with values loaded from disk.

Don't worry about time, instantiation is bloody fast. You can also
redesign your algorithm to peel out any waste and optimize it once
you get it working properly.

The three rules of software design and implementation are:
1) Make it RIGHT. (Insure the correctness [1+1 = 2 and only 2])
2) Make it FAST. (Without screwing up #1.)(see optimization)
3) Make it SMALL. (Until you screw up #2.)

The two rules of optimization are:
 Don't do anything you don't need to. (a)
 Don't do anything twice. Cache cache, cache.

a.1) That means don't go through loops any forther than you
absolutely need to. When filling a window, do not transfer a byte
that's not visible because that's a waste of time.

a.1.a) Time is something you can't buy. Not even Bill Gates can buy a
second once its gone.

a.2) That means don't hit the disk unless you absolutely need the
data. Use lazy evaluation when you instantiate a class to fetch
instances when you need them and not a moment before and ONLY if you
use them. Prefetch is nice until you've fetched something you don't
need. Then it was a waste of time. (See a.1.a)

Hope this helps,

-Charles-A.

> From: "ophir prusak" <prutwo at onebox.com>
> Organization: New York PHP
> Reply-To: talk at nyphp.org
> Date: Fri,  7 Jun 2002 10:47:32 -0400
> To: NYPHP Talk <talk at nyphp.org>
> Subject: [nycphp-talk] Object Oriented Question
> 
> 
> Hi All,
> 
> I've decided to clean up the code on my site, and at the same time
use
> object oriented code.
> I have a few ideas in my head, but I really wanted to get some input
> from others that have built projects in PHP using OO code.
> 
> Here's the problem I'm currently trying to solve (I've simplified it
> a bit and left out un-necessary details).
> My site is a video game site. Currently, my database has:
> A games table which has basic game information for each game
(game_id,
> title, console, etc)
> A reviews table which has game_id (foreign key to games table),
review
> date, review text, reviewer name and email.
> 
> If you look at this URL
> http://ps2.consolemonkey.com/reviews_date.php3?order=rev_id 
> you can see a page which shows a list of all the games and the date
for
> the most recent review for that game.
> 
> Currently I'm just doing this with a single SQL query (simple join
of
> the two tables) and echoing out the results.
> Very fast.
> 
> I'm trying to envision how to create this page using object oriented
> code.
> My initial thought was to somehow use a game object, but if I have
to
> instantiate a game object for every game, this seems like it would
have
> an enormous amount of overhead and be slow.
> 
> How is this usually done on OO projects ?
> 
> Am I missing something or would you say that if your data sits in a
relational
> database and your doing a search or mass listing of data then OO
code
> is not the way to go.
> 
> comments/suggestions/thoughts/ideas/etc ?
> 
> Thanx
> Ophir 
> 
> 
> ----
> Ophir Prusak
> Internet developer 
> prutwo at onebox.com | http://www.prusak.com/ 
> 
> 
>