Hey,
I just compiled PHP using --disable-all and realized that there's a shit
load of relatively useless stuff still being compiled into it.
The first thing I realized is that regex is still being compiled in by
default. Are any parts of PHP's core relying on regex, thus, requiring it
to be in the minimal build? I think most people today are using pcre and it
would be great if we could support a version without regex.
The second problem is in ext/standard with a zillion of functions. A lot of
them are in my opinion not used by the majority of users and it would be
great to be able not to compile them into PHP. Things that come to my mind:
a) crc32
b) cyr_convert
c) image
d) lcg
e) metaphone
f) soundex
g) levenshtein
h) sha1
i) uuencode
and probably some other stuff,
In order for PHP users to get the most out of their servers, being able to
reduce memory footprint as much as possible is quite important so that they
can increase MaxClients to as much as possible.
As we're in a code freeze for RC1 it's a bit late to do something about it,
but I think it'd be nice to brainstorm about this to see how we can solve
this, maybe for 5.1? If regex isn't required by the core that's one of the
first things I'd like to see disabled when building with --disable-all.
I think ext/standard should maybe be split up into two, the first ext/core
and the second ext/standard where ext/core is the stuff which really
needs to be part of PHP such as strlen(), file functions and pretty much
stuff I didn't list in my list :)
Any thoughts? Ideas? Flames? :)
Andi
AG>> but I think it'd be nice to brainstorm about this to see how we can
AG>> solve this, maybe for 5.1? If regex isn't required by the core that's
AG>> one of the first things I'd like to see disabled when building with
AG>> --disable-all. I think ext/standard should maybe be split up into
AG>> two, the first ext/core and the second ext/standard where ext/core is
AG>> the stuff which really needs to be part of PHP such as strlen(),
AG>> file functions and pretty much stuff I didn't list in my list :)
OK, the problem I see here is that such thing would increase PHP platform
diversity. And what I mean by that is: Suppose I am writing some PHP
application for distribution. And I use some 'weird' functions - meaning,
something beyond strlen() and other obviously 'standard' ones. As for now,
it is enough for me to say to the user "this application uses MySQL
extension" or "this application uses BlaFooBar extension" or "this
application uses only standard functions" and it would be completely
sufficient for the user to create an environment where the application
would run.
If we enable the user to individually disable the functions by standard
means, the PHP developer would have now to check if the application uses
image() and alert the user in the documentation about it - since the user
- or his provider or IT stuff - could decide it is "unneeded" and drop it
from compiled version. This means more or less everybody needs now to
remember which functions are "core" and which are "non-core". Now we have
more or less module-level granularity with clear naming so that there's no
doubt which module pgsql_connect belongs to. But enabling the user to drop
standard functions would create function-level granularity without a good
mean for the developer to know even if given function is "removable" or
not (except for memorizing the whole list, of course).
Certainly, it is possible even now to break the platform by disabling some
functions manually, but then it is messing with the code - which is much
higher barrier than altering one config option. Most users have no problem
writing some configure line but would never touch the code.
I'm concerned that this problem of breaking common platform might be more
dangerous than the performance benefit. Which, BTW, I estmate as pretty
minimal - code space is shared on all modern OSes anyway, so a little
extra code doesn't significantly impact scalability, and unused functions
usually don't claim data memory - except for, probably, symbol table
entries, but this is a small change.
With all this said, if some functions like levenstein(), soundex() etc.
might be moved to separate extension and this move would be announced,
clearly marked, etc. - it might be feasible.
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.109
Stanislav Malyshev wrote:
I'm concerned that this problem of breaking common platform might be more
dangerous than the performance benefit. Which, BTW, I estmate as pretty
minimal - code space is shared on all modern OSes anyway, so a little
I think that's a good point for leaving it the way it is: Minimal
benefit while opening a can of worms of possible problems.
Another reason not to do it is the amount of work to decide which
function should go where. Let's keep it simple and focus on IMHO more
pressing problems.
- Chris
Hello Christian,
Thursday, January 8, 2004, 2:24:33 PM, you wrote:
Stanislav Malyshev wrote:
I'm concerned that this problem of breaking common platform might be more
dangerous than the performance benefit. Which, BTW, I estmate as pretty
minimal - code space is shared on all modern OSes anyway, so a little
I think that's a good point for leaving it the way it is: Minimal
benefit while opening a can of worms of possible problems.
Another reason not to do it is the amount of work to decide which
function should go where. Let's keep it simple and focus on IMHO more
pressing problems.
Same thoughts here. The benefit is far to low. There are a lot of places
we could put our efforts into better: bug-fixing instead of creating new
bug fixes and increasing the WFT factor.
The only real reason is it php would have been meant to serve cellphones or
other small devices. But hey those run java. So we shouldn't care about a
few kilobytes (or hundreds of them).
Best regards,
Marcus mailto:helly@php.net
Hello Christian,
Thursday, January 8, 2004, 2:24:33 PM, you wrote:
Stanislav Malyshev wrote:
I'm concerned that this problem of breaking common platform might be
more
dangerous than the performance benefit. Which, BTW, I estmate as
pretty
minimal - code space is shared on all modern OSes anyway, so a littleI think that's a good point for leaving it the way it is: Minimal
benefit while opening a can of worms of possible problems.Another reason not to do it is the amount of work to decide which
function should go where. Let's keep it simple and focus on IMHO more
pressing problems.Same thoughts here. The benefit is far to low. There are a lot of
places
we could put our efforts into better: bug-fixing instead of creating
new
bug fixes and increasing the WFT factor.The only real reason is it php would have been meant to serve
cellphones or
other small devices. But hey those run java. So we shouldn't care
about a
few kilobytes (or hundreds of them).
Just to chip in my feeling that this is a low-gain proposal.
George
As Stas mentioned, I'm not sure that this is a good idea, unless
we split some of these things out of ext/standard and into their
own extensions; ext/std_regex, ext/std_string (for levenstein, soundex,
metaphone etc.), ext/std_hash (crc32, sha1) and have those extensions
compiled in by default.
IIRC, Jani was hoping for something like this a while back.
Meanwhile, the best way to reduce footprint is to disable libxml
extensions ;-)
--Wez.
----- Original Message -----
From: "Andi Gutmans" andi@zend.com
To: internals@lists.php.net
Sent: Thursday, January 08, 2004 8:10 AM
Subject: [PHP-DEV] Ability to lower PHP memory usage
Hey,
I just compiled PHP using --disable-all and realized that there's a shit
load of relatively useless stuff still being compiled into it.
The first thing I realized is that regex is still being compiled in by
default. Are any parts of PHP's core relying on regex, thus, requiring it
to be in the minimal build? I think most people today are using pcre and
it
would be great if we could support a version without regex.
The second problem is in ext/standard with a zillion of functions. A lot
of
them are in my opinion not used by the majority of users and it would be
great to be able not to compile them into PHP. Things that come to my
mind:
a) crc32
b) cyr_convert
c) image
d) lcg
e) metaphone
f) soundex
g) levenshtein
h) sha1
i) uuencodeand probably some other stuff,
In order for PHP users to get the most out of their servers, being able to
reduce memory footprint as much as possible is quite important so that
they
can increase MaxClients to as much as possible.As we're in a code freeze for RC1 it's a bit late to do something about
it,
but I think it'd be nice to brainstorm about this to see how we can solve
this, maybe for 5.1? If regex isn't required by the core that's one of the
first things I'd like to see disabled when building with --disable-all.
I think ext/standard should maybe be split up into two, the first ext/core
and the second ext/standard where ext/core is the stuff which really
needs to be part of PHP such asstrlen(), file functions and pretty much
stuff I didn't list in my list :)Any thoughts? Ideas? Flames? :)
Andi
As Stas mentioned, I'm not sure that this is a good idea, unless
we split some of these things out of ext/standard and into their
own extensions; ext/std_regex, ext/std_string (for levenstein, soundex,
metaphone etc.), ext/std_hash (crc32, sha1) and have those extensions
compiled in by default.
I also don't think it's a good idea, not even if we split out some of
the functions to new 'extensions'. The power of PHP is that it had a lot
of useful and powerful functions in the core and why would you want to
change that? The problem with moving all those core functions to their
own extensions is that they can be turned off too easily y hosters and
then just the most simple scripts can break because of some ISP
stupidity (and from what I know most of them are like that).
Derick
As Stas mentioned, I'm not sure that this is a good idea, unless
we split some of these things out of ext/standard and into their
own extensions; ext/std_regex, ext/std_string (for levenstein, soundex,
metaphone etc.), ext/std_hash (crc32, sha1) and have those extensions
compiled in by default.IIRC, Jani was hoping for something like this a while back.
I was thinking about it for increasing the maintainability
of ext/standard, not to reduce the size of the binary.
--Jani
Removing few functions from standard will not save more then a few kilobytes
from the final binary (stripped). However, it'll create problems for people
who try to write portable scripts relying on those extensions. For example
ext/ctype is pretty basic functionality and is even enabled by default.
However, many servers do not have it requiring a PHP wrapper to do the same.
While it's relatively simple to re-implement ctype, that is not the case for
some of the functions you want to remove.
Unless PHP is used for most basic tasks it is pretty useless with
--disable-all.
Removing regex is a fine idea, BUT it used by code like browscap internally.
Cooperatively speaking it would be better (binary size wise) to use regex
rather then PCRE, which while better in many respects is by no means more
compact.
-1 on the removal idea
Ilia
P.S. Here are the sizes of the striped object files for some of the functions
you want to remove:
metaphone.o (6156)
soundex.o (840)
uuencode.o (2308)
crc32.o (1660)
sha1.o (6696)
levenshtein.o (3440)
lcg.o (832)
image.o (11432)
cyr_convert.o (4104)
Overall saving <40kb, which is about 2.5% of the size of a PHP binary
Hey,
I just compiled PHP using --disable-all and realized that there's a shit
load of relatively useless stuff still being compiled into it.
The first thing I realized is that regex is still being compiled in by
default. Are any parts of PHP's core relying on regex, thus, requiring it
to be in the minimal build? I think most people today are using pcre and it
would be great if we could support a version without regex.
The second problem is in ext/standard with a zillion of functions. A lot of
them are in my opinion not used by the majority of users and it would be
great to be able not to compile them into PHP. Things that come to my mind:
a) crc32
b) cyr_convert
c) image
d) lcg
e) metaphone
f) soundex
g) levenshtein
h) sha1
i) uuencodeand probably some other stuff,
In order for PHP users to get the most out of their servers, being able to
reduce memory footprint as much as possible is quite important so that they
can increase MaxClients to as much as possible.As we're in a code freeze for RC1 it's a bit late to do something about it,
but I think it'd be nice to brainstorm about this to see how we can solve
this, maybe for 5.1? If regex isn't required by the core that's one of the
first things I'd like to see disabled when building with --disable-all.
I think ext/standard should maybe be split up into two, the first ext/core
and the second ext/standard where ext/core is the stuff which really
needs to be part of PHP such asstrlen(), file functions and pretty much
stuff I didn't list in my list :)Any thoughts? Ideas? Flames? :)
Andi