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
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>> 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
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-
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
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, 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
> 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 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
> 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
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
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
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
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
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
> 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>> 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
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
(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
(
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
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
> 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
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
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
> 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
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
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
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, 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>> 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
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;
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
32 matches
Mail list logo
