Doing some tests regarding memory allocation, I have discovered that the
implementation of smart strings (php_smart_str.h), user in spprintf and
everything above it, is kind of sub-optimal with regard to memory
allocation. That's why:
The initial string buffer is allocated of size at least 128
Fine with the concept.
If you move the additional check (newlen <
SMART_STR_START_SIZE) and preallocation into the if (!(d)->c)
branch, the changes won't affect the common code path.
> @@ -47,7 +51,11 @@
> if (!(d)->c) (d)->len = (d)->a = 0;
SS>> If you move the additional check (newlen <
SS>> SMART_STR_START_SIZE) and preallocation into the if (!(d)->c)
SS>> branch, the changes won't affect the common code path.
IMO, the common code path is that of SMART_STR_START_SIZE, since as I
said 90% of strings never reach beyond i
On Wed, 18 Jun 2003, Stanislav Malyshev wrote:
> SS>> If you move the additional check (newlen <
> SS>> SMART_STR_START_SIZE) and preallocation into the if (!(d)->c)
> SS>> branch, the changes won't affect the common code path.
>
> IMO, the common code path is that of SMART_STR_START_S
SS>> Common referred to real applications, not 'make test'.
Do you have some data about real applications in PHP that use strings
longer than 80 bytes via smart strings? My tests show most of the strings
used are small. Looking at the clients of this functions and taking into
account that p
On Wed, 2003-06-18 at 15:21, Stanislav Malyshev wrote:
> The number 80 was chosen because even if malloc allocates 128 bytes, these
> 128 bytes would be reused using the Zend memory cache. However, if the
> size of the segment does not allow it to be into the Zend memory cache,
> new malloc woul
PL>> How about including a malloc() implementation of your own? Doug
PL>> Lea's dmalloc comes to mind. That way, you should be able to get a
PL>> much higher level of control over how it allocates small blocks
PL>> (which are indeed very common in almost all computer programs).
In fact, that wa
> BTW, why do you think "make test" is a bad test of memory allocation
> patterns? What do you propose as a better test?
make test is synthetic. My primary use of smart_str involves
IRCG based application.
> That's very bad news, because actually my test show that about 95% of
> mallocs
On Wed, 2003-06-18 at 15:41, Stanislav Malyshev wrote:
> BTW, I don't exactly think dmalloc is the best way for what we are going
> to do, since AFAIK it's general-purpose allocator, and what we need is
> more to the direction of fixed-size block allocator.
Fixed-size? Do you mean an allocator
DR>> Just curious, but why a fixed size block allocator?
Because the tests show that significant part of allocations fall in the
following categories (not in this particular order by frequency):
1. Small memory allocations (below 16 bytes)
2. zval allocations
3. Hashtable allocations
4. Hash buck
> In fact, that was initial though behind all my tests - to see how many
> small blocks PHP allocates, what are these small blocks and how well they
> are cached. If anybody is interested in working or it or has suggestions
> about that - I can share my thoughts.
If you are concerned about PHP
SS>> make test is synthetic. My primary use of smart_str involves
SS>> IRCG based application.
Which tells what? What are sizes you use there in IRCG? Anyway, is IRCG
the most used client of smart strings? Since much more used printf
functions use it too, I guess that with all due respe
PL>> Fixed-size? Do you mean an allocator that is optimized for
PL>> allocation of blocks of a certain size, or an allocator that can only
PL>> allocate blocks of a certain size?
The former, which can be the latter too, since we can always fall back to
malloc.
--
Stanislav Malyshev, Zend Produ
(I don't have the time right now to write a lengthy reply)
1. malloc is expensive on some systems, and less expensive on
many others. It really depends.
2. some mallocs (Linux, Solaris probably) are optimized for
non-contentious allocations in threaded contexts
(
On Wed, 2003-06-18 at 16:11, Stanislav Malyshev wrote:
> PL>> Fixed-size? Do you mean an allocator that is optimized for
> PL>> allocation of blocks of a certain size, or an allocator that can only
> PL>> allocate blocks of a certain size?
> The former, which can be the latter too, since we can al
SS>> If you are concerned about PHP's memory footprint, then
SS>> relying on your own memory management makes matters only
SS>> worse.
SS>>
SS>> Why? It would effectively lock up memory in a PHP-specific
SS>> area, so that other 3rd party software (web server,
SS>> librarie
> This might actually be a very good idea, since it can likely improve
> performance a lot by having a pool of zval-sized blocks (I have no idea
> of how big they are). Have you thought about how to implement it in a
> good way?
Free lists already exist.
- Sascha
--
PHP Internals - PHP
SS>> 5. locking up memory in PHP and asserting that you basically
SS>>would like to reroute malloc to go through PHP's emalloc
SS>>does not sound reasonable to me.
That's not even close to what I propose. I don't want mallocs to go
thgough emalloc. Anyway, most of allocs in en
PL>> This might actually be a very good idea, since it can likely improve
PL>> performance a lot by having a pool of zval-sized blocks (I have no idea
PL>> of how big they are). Have you thought about how to implement it in a
PL>> good way?
I did think about it, but didn't come to any conclusions
On Wed, 2003-06-18 at 16:19, Sascha Schumann wrote:
> > This might actually be a very good idea, since it can likely improve
> > performance a lot by having a pool of zval-sized blocks (I have no idea
> > of how big they are). Have you thought about how to implement it in a
> > good way?
> Free li
SS>> > This might actually be a very good idea, since it can likely improve
SS>> > performance a lot by having a pool of zval-sized blocks (I have no idea
SS>> > of how big they are). Have you thought about how to implement it in a
SS>> > good way?
SS>>
SS>> Free lists already exist.
Yes, of
SS>> If you move the additional check (newlen <
SS>> SMART_STR_START_SIZE) and preallocation into the if (!(d)->c)
SS>> branch, the changes won't affect the common code path.
Ok, I have rewrote the patch, please see in attachment. It got somehow
more inflated, but it now has no more t
> That's good, but that's only one step. Some system mallocs are very
> inefficient on small blocks so it might be very worthwhile to grab a
> "chunk" of, say, 64k, instead of many small mallocs of 20 bytes.
How do you know that this is a significant problem?
Quantify first, optimize lat
On Wed, 2003-06-18 at 16:56, Sascha Schumann wrote:
> > That's good, but that's only one step. Some system mallocs are very
> > inefficient on small blocks so it might be very worthwhile to grab a
> > "chunk" of, say, 64k, instead of many small mallocs of 20 bytes.
> How do you know that this
> fairly certain that doing 100 000 allocations of 20 bytes is a whole lot
> 1) slower and 2) more memory consuming than allocating 2 megs at once.
Of course. That's not the point though. The point is
whether the difference matters in the global picture.
You can optimize almost ever
On Wed, 2003-06-18 at 17:24, Sascha Schumann wrote:
> Of course. That's not the point though. The point is
> whether the difference matters in the global picture.
Point taken. But is it such a big thing? I mean, writing a special
case in the emalloc() is not too time-consuming. Benchmark it w
On Wed, 2003-06-18 at 09:21, Stanislav Malyshev wrote:
> SS>> Common referred to real applications, not 'make test'.
>
> Do you have some data about real applications in PHP that use strings
> longer than 80 bytes via smart strings? My tests show most of the strings
> used are small. Looking
On Wed, 18 Jun 2003, Per Lundberg wrote:
> On Wed, 2003-06-18 at 17:24, Sascha Schumann wrote:
> > Of course. That's not the point though. The point is
> > whether the difference matters in the global picture.
>
> Point taken. But is it such a big thing? I mean, writing a special
> case in the
SH>> Yep. cURL uses smart_str pretty extensively for reading data from
SH>> the client. I have it alloc things in 4k chunks.
OK, point taken, though my patch does not influence cuRL in this case :)
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/ +972-3-
SS>> since end of 2001. And for ZE2, Sterling reported a 20%
SS>> increase in performance after disabling the memory manager.
You mean "zend MM memory manager" or "ZE1 memory cache manager"?
If you talk about the former, it's known issue and it is not what I was
talking about.
--
Sta
On Wed, 18 Jun 2003, Stanislav Malyshev wrote:
> SS>> since end of 2001. And for ZE2, Sterling reported a 20%
> SS>> increase in performance after disabling the memory manager.
>
> You mean "zend MM memory manager" or "ZE1 memory cache manager"?
> If you talk about the former, it's known
SS>> The point here was that designing general memory
SS>> optimizations is not trivial and that such attempts have
SS>> failed in the project's past. So, unless you find a major
SS>> flaw and a failsafe way to fix it, don't waste your (and our)
SS>> time.
Well, it's actually
I want to translate the PHP documentation in Bangla (BN) language and maintain it.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi all,
this is the second version of my patch regarding the SNMP value retrieval. If
you want to know more, please have a look at my previous explanation:
http://www.phpbuilder.com/mail/php-developer-list/2003011/0449.php
(And BTW, for some PHP security fun, have a look at:
http://www.phpbuilde
what it is meant to do:
take a querystring set it to a session variable (outputs error if neither
querystring nor sesison exist) then reloads the page (to remove the
querystring)
what it (appears) to do:
it sets the querysting to the session, reloads the page and outputs an error
saying it doesn't
At 6/18/2003 02:51 PM, Logan McKinley wrote:
> <-- the code in question >
> I have attached the actual files if that would be of more help,
> Thanks in advance for any help,
The first thing that I noticed is that you're doing error checking in
"registration_form.php", but your form i
This is the first release candidate of the upcoming maintenance
release of PHP 4.3.3.
Please download and test it as much as possible on real-life
applications to uncover any remaining issues.
Sources:
http://downloads.php.net/jani/php-4.3.3RC1.tar.bz2
http://do
What about to start discussing about managment of binary pecl
packages?
I'm not the best person for listing the requirements, but here are some
ideas:
pecl package name
-
The name of the extension would be:
peclfoo-bin---3.1.2-.tgz
The os (Operating system) and arch (CPU type)
Hello Tomas,
Why not using RPMs? Only windows is a problem, isn't it ?
regards
marcus
Thursday, June 19, 2003, 1:19:36 AM, you wrote:
TVVC> What about to start discussing about managment of binary pecl
TVVC> packages?
TVVC> I'm not the best person for listing the requirements, but here are s
On Thu, 19 Jun 2003, Marcus Börger wrote:
> Why not using RPMs? Only windows is a problem, isn't it ?
Windows is the primary platform we need binaries for.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Wed, 18 Jun 2003, Rasmus Lerdorf wrote:
> On Thu, 19 Jun 2003, Marcus Börger wrote:
> > Why not using RPMs? Only windows is a problem, isn't it ?
>
> Windows is the primary platform we need binaries for.
And many major Linux distributions do not support RPM...
--
Ken Tossell
ken at tossell
This is what I can think of for a concrete todo before the beta...
http://www.php.net/~sterling/php5/BETA
any thing i missed? anything extraeneous?
-Sterling
--
"Nothing is particularly hard if you divide it into small jobs."
- Henry Ford
--
PHP Internals - PHP Runtime Development Mail
PHP Programming Development
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Thursday, June 19, 2003 1:26, Marcus Börger wrote:
> Hello Tomas,
> Why not using RPMs? Only windows is a problem, isn't it ?
RPM is supported too, just do a "pear makerpm ". The command
still need some work for pecl packages, but will be avaible as soon as
the binary distrib system is set.
On Thursday 19 June 2003 12:39 am, Ken Tossell wrote:
> >
> > Windows is the primary platform we need binaries for.
> And many major Linux distributions do not support RPM...
But would that matter?
Slackware users are used to compiling everything by hand - having only rpm's
avaliable is pretty c
Actually I'm working on the php5 version of ext/java extension :)
Moriyoshi
Sterling Hughes <[EMAIL PROTECTED]> wrote:
> This is what I can think of for a concrete todo before the beta...
>
> http://www.php.net/~sterling/php5/BETA
>
> any thing i missed? anything extraeneous?
--
PHP Inter
Hello,
On 06/18/2003 09:04 PM, Gareth Ardron wrote:
On Thursday 19 June 2003 12:39 am, Ken Tossell wrote:
Windows is the primary platform we need binaries for.
And many major Linux distributions do not support RPM...
But would that matter?
Yes, it would not matter but if you want to have a sing
We also need to sort out the mbstring license mess. We cannot distribute
code that is under the LGPL and modified by us. The relevant clauses from
the LGPL:
2. You may modify your copy or copies of the Library or any portion of
it, thus forming a work based on the Library, and copy and di
On Thu, Jun 19, 2003 at 01:19:36AM +0200, Tomas V.V.Cox wrote:
> package creation
>
>
> pear build -b peclfoo-3.1.2.tgz
>
> The -b (or --bin) option generates the package containing only the
> compiled extension and the files marked with role "php", "doc", "test",
> "data" or "s
Maintaining translation of spanish documentation.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I've added the mb stuff to the list.
Can the extension itself be considered a complete work? Therefore by
distributing the extension (under the LGPL) without modifications with
PHP, we essentially keep the cancer isolated?
-Sterling
On Wed, 2003-06-18 at 22:12, Rasmus Lerdorf wrote:
> We also n
On Wed, 18 Jun 2003, Sterling Hughes wrote:
> I've added the mb stuff to the list.
>
> Can the extension itself be considered a complete work? Therefore by
> distributing the extension (under the LGPL) without modifications with
> PHP, we essentially keep the cancer isolated?
We would have to arg
Sure. PECL is a proof of that. ;-)
-Sterling
On Wed, 2003-06-18 at 23:47, Rasmus Lerdorf wrote:
> On Wed, 18 Jun 2003, Sterling Hughes wrote:
> > I've added the mb stuff to the list.
> >
> > Can the extension itself be considered a complete work? Therefore by
> > distributing the extension (und
Hello,
I'm new to the world of contributing code for open source projects. Please let
me know if I'm doing something incorrectly.
I propose that a new type, 'Z', be added in order to allow the extension coders
access to the zval** which was available with the now deprecated
zend_get_parameters().
When I get a little more time (in about 2 months!) I will be completing the
work that I started on the .MSI installer generator for PHP.
This will generate an installer for the PHP distribution (including PEAR)
based on the .zip binary distros cooked by the snaps machine and meta data
from the sou
56 matches
Mail list logo
