# Ability to lower PHP memory usage

- Thread: https://externals.io/message/6845
- Original archive: https://news-web.php.net/php.internals/6845
- Started by Andi Gutmans on 2004-01-08T08:10:59+00:00
- Messages: 9
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #6845 — Andi Gutmans — 2004-01-08T08:10:59+00:00

URL: https://externals.io/message/6845#6845

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

---

## #6846 — Stanislav Malyshev — 2004-01-08T08:36:38+00:00

URL: https://externals.io/message/6845#6846 · In reply to: #6845

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

---

## #6847 — Wez Furlong — 2004-01-08T12:30:19+00:00

URL: https://externals.io/message/6845#6847 · In reply to: #6845

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) 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

---

## #6848 — Derick Rethans — 2004-01-08T12:49:40+00:00

URL: https://externals.io/message/6845#6848 · In reply to: #6847

> 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

---

## #6849 — Christian Schneider — 2004-01-08T13:24:33+00:00

URL: https://externals.io/message/6845#6849 · In reply to: #6846

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

---

## #6852 — Ilia Alshanetsky — 2004-01-08T14:15:31+00:00

URL: https://externals.io/message/6845#6852 · In reply to: #6845

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) 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

---

## #6853 — Jani Taskinen — 2004-01-08T16:43:42+00:00

URL: https://externals.io/message/6845#6853 · In reply to: #6847

>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

---

## #6858 — Marcus Boerger — 2004-01-08T17:22:27+00:00

URL: https://externals.io/message/6845#6858 · In reply to: #6849

Hello Christian,

Thursday, January 8, 2004, 2:24:33 PM, you wrote:

> Stanislav Malyshev wrote:
> > […]

> 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

---

## #6863 — George Schlossnagle — 2004-01-08T17:49:12+00:00

URL: https://externals.io/message/6845#6863 · In reply to: #6858

> Hello Christian,
>
> Thursday, January 8, 2004, 2:24:33 PM, you wrote:
>
> > […]
>
> > […]
>
> > […]
>
> 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