Login | Register
My pages Projects Community openCollabNet

Reply to message

* = Required fields
* Subject
* Body
Send reply to
Author (directly in email)
Please type the letters in the image above.

Original message

Author Pedram Nimreezi <zenstyle@gmail.com>
Full name Pedram Nimreezi <zenstyle@gmail.com>
Date 2006-10-01 09:38:18 PDT
Message I took out 99% of the _once stuff from the php4/php5 compatible distro of
creole and propel... btw I asked about this all the way to the top...
here's what I got.

[11:18] DaedZen: i should pretty much remove all include_once/require_once's
[11:18] Rasmus: DaedZen: never use any of those Daed.. no conditional
declarations, no include_once, no autoload
[11:19] DaedZen: they wouldn't reinclude anyway.. I just do that from habit
[11:19] DaedZen: ok so i can safely take them out
[11:19] Rasmus: There are 2 separate problems with include_once.
First, it is optimized for non-opcode cache use in that it always
opens the file
[11:19] DaedZen: oh well thats good to know
[11:20] Rasmus: that means you touch the disk when you don't need to.
And second, it means any declarations in that op_array are now
conditional and thus will have to be done at execute time
[11:20] Rasmus: yes, it is a very very bad habit to always use include_once
[11:20] Rasmus: might as well put a sleep 1 in all your scripts
[11:20] DaedZen: ouch
[11:20] DaedZen: understood

note: (Rasmus is obviously being jovial about the sleep 1, but also
being honest)

I have MY version of creole and propel which again works in both versions of
the zend engine and tries its absolute level best to avoid the use of
declarations, include/require_once's or autoloading... but remember my
version is optimized for ajax and comet and json and seo and cms all
the stuff people don't necessarily or summarily include in their
benchmarks or development schedules... that are to me, today, (required).

I was around for the start of Mojavi which is now kind of
Symfony/Agavi... this approach is almost academic and suffers a
significant performance run down in my experience when fully loaded
and are from what I've seen extra layers of bloat
added onto the fine work of Sean Kerr, my good friend... (mojavi author)

I've seen requests per second for these setups to be as low as
8 to 10 requests per second... if Mambo/Joomla can provide 50 times the
functionality at the same speed, and is more than a skeleton
framework well.. that is just unfortunate.

I don't like the CMS approach to php application design because its
mostly procedural and phpnukish in its design, which is the reason I
had to design Rapid Framework which is a clandestine mix of these
requirements but with a simple way to augment the framework
functionality (adding controllers) and having search
engine friendly url's and adding content and ajax and comet and many
other features I haven't had time to do a full write up on... which
I'll be happy to give
away... thus the reason I asked about the PHP like BSD licensing for the
php 4 version instead of the LGPL licensing, which I've never really
gotten a clear
answer on....

The "proper" CMS approach to web site design is an exceptionally strong method
of achieving high search engine visibility, and lots of traffic, it
works off a set of
"rules" that very few developers have even the foggiest idea of and
usually only
identify to the "odd behaviour" of "mediocre sites" having "so much
more traffic"
then their fine craftsmanship... it all comes down to application design where
one is coded to be effective and one is coded to be pretty, I went for both, I
like very very clean code and very very high search engine rankings which
can be combined but usually aren't because the developers are from entirely
different schools...

/acme-h15-long-range​-coyote-hunting-rifl​e.html is always going to beat,
?module=cart&act​ion=product&id=5​ even /cart/products/5.html or a variation

but that doesn't mean the first url cannot imply that it means the second url.

And these are some of the things I needed, didn't have correctly and
had to make.

Let me know if you guys need anything more of me...

On 10/1/06, David Z├╝lke <dz at bitxtender dot com> wrote:
> > However, according to what I've read, the hit it *slight* and not
> > *huge*. But how can I know until I see numbers that actually test
> > the require_once part. This means setting up a bare-bones example
> > without large code (as compiling time masks the true hit of the
> > _once call). Or better yet, some profiling numbers of the same code
> > running with require vs. require_once and looking at the results.
> Prior to 5.2 and the latest APC, _once calls were not accelerated _at
> all_ by APC because there was no way for a cache to hook in.
> > My worry is that people are starting to thing require_once is slow
> > *in general* which it isn't. I believe that it is slower with
> > opcode caches (although I don't see why, granted I haven't looked
> > into it and I'm sure it's complicated).
> It is slower than a regular require. I recently threw out all but one
> _once call from Agavi, and with APC (on 5.0.4), the page rendering
> time dropped by 50(!) percent.
> > I am concerned that wholesale replacement of _once with the non-
> > _once versions is a bad idea. They are not logically equivalent on
> > their face!
> >
> > Before we go and make such a change, I'd like to have a discussion
> > about it.
> >
> > - One option suggested was that require_once inside of autoload is
> > redundant; that since it's autoload you can be sure that you'll
> > only load a file exactly once anyway, b/c once it's loaded autoload
> > () won't get called again for that class or any other class in that
> > file.
> Of course. Using _once inside an autoload is utterly stupid. Why
> would you do that. It only gets called when the class was not found
> anyway ;)
> I emailed the APC dev list during the discussion in the other thread,
> and Rasmus said that while dynamic/conditional loads (e.g. a require
> inside an if, or an autoload) are accelerated by APC, too, there
> won't be the same amount of improvement over a straight require(). I
> still believe that autoload is the better solution; not only because
> it makes things cleaner, but also because it offers the most fine-
> grained JIT-style loading you could possibly have with next to no
> effort as opposed to require calls, where you might end up loading
> more than you need in the specific situation.
> > - Another option is to write your own require_once. I kinda did
> > this for one of my projects, and it works. I think the reason
> > require_once is goofy is that it handles a lot of situations that
> > most code would not need to rely on. For instance, if one does
> > "require_once 'a/b/c.php', and there are 5 directories in
> > include_path, then technically there are 5 different solutions to
> > that require_once. I am guessing maybe that a lot of the quirkiness
> > of the _once calls is dealing with stuff like this. I wrote my own
> > require once that implements the _once part simply by keeping track
> > of whether or not that exact string has been included before, and
> > if so, simply exits, and if not, calls the non-_once counterpart to
> > require/include it. This seems to work functionally, and seems that
> > also it might avoid the _once hit discussed on the opcode cache
> > forums.
> We had some guys on #agavi who did that since APC prior to PHP 5.2
> would randomly produce errors about classes not found - turned out
> the _once stuff was the problem.
> David
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org

Pedram Nimreezi -- President/Senior Engineer
Major Computing, Inc

Not by age, but by knowledge is wisdom acquired.