Re: Instantiation of class objects

Szii wrote: > On Thursday 21 December 2000 14:58, Ignacio Vazquez-Abrams wrote: > > It can't tell if the object(s) you're instantiating are going to be used > > the same way, or for the same thing, or what, and AFAIK there's no surefire > > way of reinitializing old objects, so there's no point in caching them. > It has to have SOME kind of run-time knowledge. If you say "new foo()" > and then later (in another script) Days, months, years?... after it has been set up and thrown away when the program ends (page finishes loading)?...hm.... filesystems are good for caching data like this. ;-) > say "new foo()" I would think that the > object would have been cached from the other script and could be reused. Well, there are a few approaches to take, none of which have seemed "clean" enough to put into PHP. Part of the problem is with inherently dynamic data, say, for example, a database select method in an object. That select needs to be called every time, because the data may have changed. That means that the cache is no good. Or an object which is called based on user supplied data, where each user may be supplying different variables.... cache is no good. An auth lookup, where the auth permissions can be changed... cache is no good.... One way to do this, of course, is store the object's data outside of PHP, but you still need to initialize a new object when you run the program again (such as loading a web page). This pretty much means that what you're looking for fast storage, which is why some developers are using shared memory for caching of general data.... I guess if you were feeling really clever, you could cache PHP code for an object in there, but it would make more sense to cache the data of that object, and access it as you see fit. > The test objects we're using are small...tiny in fact. They have > 3 member variables, 1 method, a constructor which calls the parent > constructor and that's it. Since it's only 1 parent and 1 child (not nested > deeply) it shouldn't give THAT much overhead. If you find ways of optimizing the PHP OO code, I'm sure it would be greatly appreciated.... > I would love to see the > Zend engine implement some kind of caching and a callback/hard call > into the method to reinit it. (Maybe re-call the constructor method > explicitly?) Well, within the boundaries of an execution, this is trivial (and probably already done?). But there are two ideas mixing here, one being caching of an object for a code execution session (a page load) and the other being caching across an indeterminate number of program executions (more than one page load). > One of the main ideas of objects (obviously) is reuse. As others have noted, the reuse of objects has nothing to do with a computer CPU reusing the code. It's about the programmers reusing the code. > What good is reuse if you take a huge performance hit? 1000 programmer hours are a *lot* more expensive than buying 15 linux boxes... so if you can save on programmer labour by reuse, and build a cluster of servers, you can save money and time on a project. It really shines on the subsecquent iterations of a project, as initial authoring in OO tends to be more time consuming, but maintenance and reusing the code later in the project it usually much faster. > You gain > maintainability but lose such a huge performance benefit that it (at least > for us) is going to cause us to NOT use objects - even as much as we'd > love to. Well, drawing a bright line like this can be just as questionable as insisting that "all code must be objects!". Use what works, when it's needed, and compensate for the flaws. Procedural programming sucks, OO sucks. So use what sucks _less_ for a given task.... Let me tell you a story, about a conversation I had with Ed Post (author of the internet humour classic "Real programmers Don't use PASCAL"). Ed told me about a chunk of code he had written, 30 lines, a single page. It performed all the necessary tasks, it was clear, easy to maintain, easy to understand. But it was too slow. So he went to another programmer, and they figured out how to optimize it within the context of the other code, the target platforms, how to elimiate excess logic and loops.... When it was done, two weeks later, it was 24 pages long.... and ran 20 times faster. It was ugly, it was hard to debug, but it was much, much, faster. So, when debating using any given code paradigm, you really have to ask yourself about the given goals for that piece of code. Is it worth tuning for speed? Is it more important to be debuggable, and portable? Are programmer hours or CPU more expensive? -Bop -- Personal: ron@opus1.com, 520-326-6109, http://www.opus1.com/ron/ Work: rchmara@pnsinc.com, 520-546-8993, http://www.pnsinc.com/ The opinions expressed in this email are not neccesarrily those of myself, my employers, or any of the other little voices in my head.