Avoiding repetitave processing (parsing ..) of large static code sections

[TodAB]

I have an application that creates objects from elements in a database.  The process involves a lot of processing and cross referencing.  I now generate a source file containing a large set of object instantiations.  In the course of any one request, only a few of these objects are used.  Also, these objects do not get changed during execution, but are more like constants.  I cannot determine which will be needed based on the input alone.  Is there a way to create these objects so that I can use the same (identity) objects for each cycle through the process.  My goal is to improve performance.

 

I can translate the code into most any language needed.  I looked at adding functions to the runtime, or having some other service carying the code.

 

Tod

[Buyocat]

Well more details may help make this clearer but it sounds like there are several things you could do to help reduce the number of objects you're creating.  Just as an aside if you ever find yourself constructings many tens or hundreds of objects you should probably take a step back.  So the trick, well there are several options as I said, let me start with a list:

1. Singleton pattern

2. Flyweight pattern (related to the above)

3. Lazy loading/instantiation

 

That's what I have off the top of my head, so let me explain each a little bit, and if you have any questions or want to pursue one option deeper feel free to ask.

 

1. Create a mechanism (class, function, something) which generates and returns a single instance of an object.  For example, if you wanted to create a large object (say a database abstraction object) that was expensive to instiate you might instead use a singleton factory and use that to restrict all references to the DAO to a single object.  A sample implementation:

class Foo {

public static functiongetSingleton() {
    static $singleton;
    if (!isset($singleton))
        $singleton = new Foo();
    return $singleton;
}
}

 

2. Related to the above implementation, you could create a registry which returned single instances of classes which had no context specific data.  The method signature might be something like:

// returns a Character object
public function getLetter($character);

With this you could construct hierarchies of character objects based on the promise that none of the character objects' state would change.  So if you imagine working with just 26 characters then you would need only 26 objects to represent however many letters were typed by the user.  The implementation of this approach would involve the singleton pattern and a hash table, most likely.

 

3. Finally you could create a proxy for your objects, say between the object and the database.  So, when the object was created none of its internal state would be pulled from the database, and no database connection would be established.  The object would just be created with it's internal state unset.  Then when some data was requested the object could either fetch that data then, or fetch all of its data (this might be determined based on the assumption that if called once the object is likely to be called again).  The proxy would stand between the user request from the object and the object's state, and would trigger a database look up when the state was null, let's say.

 

I hope some of those are useful, and feel free to ask some more questions.

[TodAB]

Buyocat:

 

Thank you for the considerable time spent on your answer.

It appears that I was not sufficiently clear in my post.

 

As I understand the process, EACH time a request is made

to the Apache server, a new thread of the php processor

is created.  The session information is made available (bound)

and the requested (code) page is read and parsed for syntax.

Control is passed to the s-code? of the page and the program

"starts".  As I encounter other required pages, these too are

read and parsed. 

 

Objects are created at runtime by the program.  If session

control is used, the objects are de-serialized from the session

file. This requires that the class code be present.  In my case

I think the effort to create the objects from php code or loading

from a session is less than from the database.  I would like to

avoid this problem and have the stuff available all the time.

 

The problem I am trying to solve (an expert system) is made

easier by having the names representing knowlege objects be

created from the text entered to specify purpose of the object. 

For example "boiler" is an object that contains knowlege about boilers. 

I parse the users textual data use the variable name resolution function

of php to resolve to the object I need.  There are a great number

,about 500, of these objects which are currently loaded as php code.

Each object returns other object names as part of its function.

(this is probably not too clear)

 

I do this for EACH request.  I would like to have these objects,

or functions if need be, available as part of the php environment

without having to load from the session or parse from the php

each time.  One book gave instructions for creating custom

functions or libraries? and binding them into php before starting

the server and runtime php.

 

Tod

[TodAB]

To add some more information.

 

The function of the main class in my system is to define a specific condition

that might be found in the users data (text), and hold relationships between

these conditions.  Each is defined as a list of words (pairs), a statement, a

question, then some more words.  These do NOT change during the running

of the service, for weeks.  A separate structure similar to Lisp's oblist is used

to hold the current state of the computation.  On each request to the server

the updated "text" is returned from the client, stored in the database and then

used as the only input to drive the process.

 

Assume each word or words in the text may match a condition in some object.

For any set of input, hopefully, some objects be triggered and record the fact

in a global static list.  As this happens, conditions represented by other objects

may be triggered.  The result is both an analysis and a question being returned

to the user as the response.  This happens until the set of conditions becomes

decidable.

 

In actual use, only about 10 or so of the 500+ defined conditions are actually

used.  In my mind, as a legacy programmer from the 70's, this is extremely

wasteful.  That is why I would like to spend the memory to make this knowlege

static with respect to the php environment instead of created each time.

 

The actual design of the classes needed to implement and isolate the various

functions or behaviors is well in hand and seems to work well.  If only those

objects known to be needed for a particular case are loaded, the performance

is well above expectations.  If all of the classes are loaded, the performance

falls off a bit but is not noticed at this point.  I expect a 100 fold increase in

load as the system rolls out.  Then this will be cone a problem.

 

My other solution is to create second (virtual) server in Java that implements

the actual analysis, because the objects are more persistant over the long run.

 

Tod

[kathas]

I dont know if i have totally understood your problem here but i will give it a try...

 

As i see it you have a lot of classes loaded while you create instances of a small number of them...

So you think that it would be better to load only the ones you want to create an instance of...

 

you could use the include function to load the class you need right at the time you want an instance of it...

or if you use php5 you could create a magic method to load the classes automatically... with this you could just create your instances and let them be loaded on them selfs... Autoloading Objects - Manual

 

Hope I've helped...

 

Kathas