Maintaining OpenBSD documentation on php.net. The old maintainer of the OpenBSD php
port and documentation on php.net is stepping down.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Sat, 24 Apr 2004, Jason Garber wrote:
> If each file_exists() call uses one or more stats, then I must say that a
> stat is a very quick operation.
It's all relative. Like we stated earlier, most PHP users really couldn't
care less about stat overhead. It also depends on your operating system
Hi,
One of the questions that I have is "how long is long?". Here is an
interesting example of a large system that I work on.
On the first line of each script, we have a line like:
require_once('izfc.core4.php'); //exists in global include path
The job of that script is to find and include all
Hi,
attached a patch to fix the protos for ext/sysvsem/sysvsem.c against
php4 HEAD.
Regrads
Friedhelm
Index: sysvsem.c
===
RCS file: /repository/php-src/ext/sysvsem/sysvsem.c,v
retrieving revision 1.41.2.3
diff -u -u -r1.41.2.3 sysv
On Apr 24, 2004, at 12:29 PM, Rasmus Lerdorf wrote:
On Sat, 24 Apr 2004, George Schlossnagle wrote:
Well, I disagree that this is anything like a realpath(). If your PEAR
directory is the first thing in the include_path (as in get rid of "."
from it) then this is a single stat call on any PEAR
On Sat, 24 Apr 2004, George Schlossnagle wrote:
> > What do you mean by that? APC doesn't require anything near a
> > realpath.
> > If you get rid of realpath() in PHP, APC will work just fine. With my
> > syscall hacks I am using APC this way and I just have 1 stat per file.
> > The only visible
On Apr 24, 2004, at 11:43 AM, Rasmus Lerdorf wrote:
On Sat, 24 Apr 2004, George Schlossnagle wrote:
A nitpick - apc now uses device/inode information and not the file
name
as hash keys. It's no less or more expensive before, both require an
equivalent of realpath() (actually in the apache case t
Hello all,
I need your help -- for weeks I have been banging my head agaist this wall:
I simply want to build an PHP Apache DSO against the apache src tree. However, it
seems that the PHP configure script expects the Apache Win32 binaries to link against.
On make, I alwasy run into this erro
On Sun, 25 Apr 2004, Alan Knowles wrote:
> Which is really why the RFC needs to be backed up by a good indepth
> discussion of the performance issues and possible solutions (which you
> and Rasmas do wonderfull job of :)
To the blackboard with you! Write my name 10,000 times so you will never
get
b) let apc_include_file, check if the file has been pre-compiled
(based on the a hash lookup of the filenames) , or call the standard
zend_compile code.
A nitpick - apc now uses device/inode information and not the file name
as hash keys. It's no less or more expensive before, both require a
On Sat, 24 Apr 2004, George Schlossnagle wrote:
> A nitpick - apc now uses device/inode information and not the file name
> as hash keys. It's no less or more expensive before, both require an
> equivalent of realpath() (actually in the apache case the new version
> is twice as efficient as the ol
On Apr 24, 2004, at 10:29 AM, Sebastian Bergmann wrote:
George Schlossnagle wrote:
1) it's not as simple as it sounds, especially if you have includes
that do more than just declare functions and classes.
Who said anything about this beeing easy? Easy is boring ;-)
As far as 1) is concerne
Hi,
Maybe the PEAR Packager / Installer could be changed to (optionally?)
create a single source file (without require/include statements)
comments, whitespace) from all role="php" s and use this for
deployment.
This should not be done, as a lot of packages are driver based.
If you create
On Apr 24, 2004, at 10:17 AM, Alan Knowles wrote:
Would these changes be incorporated into PHP4, too?
On a related note -- would it be possible (if not already done) to
evaluate dirname(__FILE__) at "parse time", in case that gives you a
performance advantage? Or is there a better way to do "re
George Schlossnagle wrote:
> 1) it's not as simple as it sounds, especially if you have includes
>that do more than just declare functions and classes.
Who said anything about this beeing easy? Easy is boring ;-)
As far as 1) is concerned: this should not be a problem with PEAR
packages
On Apr 24, 2004, at 10:18 AM, Sebastian Bergmann wrote:
Christian Schneider wrote:
I guess someone _that_ considered about performance could easily do a
cat *.php | grep -v require | php -w >app.lib
or the like and include app.lib.
Maybe the PEAR Packager / Installer could be changed to (optiona
Christian Schneider wrote:
> I guess someone _that_ considered about performance could easily do a
> cat *.php | grep -v require | php -w >app.lib
> or the like and include app.lib.
Maybe the PEAR Packager / Installer could be changed to (optionally?)
create a single source file (without requi
Would these changes be incorporated into PHP4, too?
On a related note -- would it be possible (if not already done) to
evaluate dirname(__FILE__) at "parse time", in case that gives you a
performance advantage? Or is there a better way to do "real" relative
includes?
theoretically, if the file
Andi Gutmans wrote:
At 01:49 AM 4/24/2004 -0700, Rasmus Lerdorf wrote:
Overall I think you would get more bang for the buck by coming up with an
intelligent caching stat/realpath implementation. The obvious drawback
would be that symlinks and other filesystem changes done while the server
is runn
Christian Schneider wrote:
> [...]
I guess someone _that_ considered about performance could easily do a
cat *.php | grep -v require | php -w >app.lib
or the like and include app.lib.
Well yeah, it gets slightly harder when you dynamically require modules.
Cheers,
Michael
--
PHP Internals - PHP Ru
At 01:49 AM 4/24/2004 -0700, Rasmus Lerdorf wrote:
Overall I think you would get more bang for the buck by coming up with an
intelligent caching stat/realpath implementation. The obvious drawback
would be that symlinks and other filesystem changes done while the server
is running would not be seen
Relax :)
Edin is the person in charge of the win32 snap builder,
and no doubt he will take a look at upgrading curl when
he has the opportunity.
As for contributing to the PHP project, try looking at
one of the numerous readme files in the php source itself.
--Wez.
- Original Message -
On Sat, 24 Apr 2004, Alan Knowles wrote:
> Thanks - I just had a look through
> zend_comple.c:zend_include_or_eval_handler
>
> it appears that zend_stream_open .. and hence fopen is called on every
> require_once/include_once
>
> would it make sense to add something as simple as
>
> if (opline->op2
Thanks - I just had a look through
zend_comple.c:zend_include_or_eval_handler
it appears that zend_stream_open .. and hence fopen is called on every
require_once/include_once
would it make sense to add something as simple as
if (opline->op2.lval == ZEND_REQUIRE_ONCE) {
locations = get_p
On Sat, 24 Apr 2004, Christian Schneider wrote:
> Rasmus Lerdorf wrote:
> > 1. The included_files list gets updated each time you include a file. In
> >order to make sure that the same file included by different paths or
> >symlinks don't conflict we do a realpath() on the file to be inclu
Rasmus Lerdorf wrote:
1. The included_files list gets updated each time you include a file. In
order to make sure that the same file included by different paths or
symlinks don't conflict we do a realpath() on the file to be included.
That's done by PHP, not APC, right? Does this only apply
26 matches
Mail list logo
