[rfc] 64bit usage, actual memory usage using real life apps

hi,

So here are the first numbers:

peak mem usage:

Wordpress master: 24.33Mb
Wordpress str_size_and_int64: 25.72Mb
delta 5.4%

Symfony master: 26.59Mb
Symfony str_size_and_int64: 27.19Mb
delta 2.2%

Drupal master: 23.46MB
Drupal str_size_and_int64: 24.60Mb
delta 4.63%

There is indeed more memory used but it is less than one could expect
and very acceptable given the benefits provided by the patch.

Also we may see more gains if class/variable/etc names use int32
instead of size_t, as Stas pointed out it makes little sense in this
case and the implementation is much safer than any other areas in the
core (or other extensions).

Read "more gain" as "less degradation".

No, I mean more gain.

But it is nice to see that actual numbers are being ignored, we go
from your 8% to a medium increase to something closed to the "measures
margin errors" level, but heh, who cares?

I feel confident that we can even get better results with phpng, once
we get the time to actually merge the 64bit patch and do further
analyzes while stabilizing phpng.

I wouldn't be so confident, before seeing the results.

Which won't and can't be seen before phpng is somehow usable and
testable. We are very far away from that.

The relative memory consumption increase on phpng is going to be more
significant.

With the risk to repeat myself, phpng is by far not ready. We have
proven that the impact of the 64bit patch is not significant, from a
memory and performance point of view. The memory results can be seen
here and in the other tests we published. The performance as well, and
we have to keep in mind that it performs equally or better with many
widely used applications.

Now, for what I understand, no matter what we do or provide, you guys
are going to refuse this patch, with absolutely no valid reason but an
hypothetical change that may be ready in a timely manner for php-next.
Given that it is in an acceptable state, both from a stability and API
point of view. This is definitively a bad thing and I am not sure that
will end well for php as a project or language. Or did I miss
something that could tell me that you may actually be more
cooperative?

Cheers,
Pierre

Even 4% is very big if you provide a high performance web application.

4% memory increase? Not really.

There is indeed more memory used but it is less than one could expect
and very acceptable given the benefits provided by the patch.

Also we may see more gains if class/variable/etc names use int32
instead of size_t, as Stas pointed out it makes little sense in this
case and the implementation is much safer than any other areas in the
core (or other extensions).

I feel confident that we can even get better results with phpng, once
we get the time to actually merge the 64bit patch and do further
analyzes while stabilizing phpng.

I have to ask anyone to actually look at these numbers and the
benefits (see the other thread "on memory usage with the 64bit patch,
and interpretation of various numbers").

Pierre, I don't understand you in the following points:

You argument the size_t for string length is to use well defined C types and
that makes it more safe. But it is only an integer type that can overflow in
the same way any other integer can do. And as Nikita pointed already the
type exists to support ALL possible objects.
In which case it makes it more save?

Please see the links in the other thread, it is very well explained,
much better that what I could do.

Why you think the size_t type is more safe for string length but in the case
for class names it's ok to use a smaller type?

Because we already have safety checks for string lengths etc. We also
already had issues related to this area. Take it as a compromise, but
still safe (while phpng may bring its lot of issues too, but that's
expected).

I often hear in this thread (and phpng) we do support string length up to
2GB on 32bit systems already and therefore should increase it for 64bit
system to the max possible value.
In my opition it's simply not true in practice because on 32Bit systems your
system can manage max. 2^32bytes and one PHP process isn't the only process.
I think the same argment exits on 64bit system.
So for me we should reduce the max. string length down as nobady can use 2GB
strings in PHP regardless what integer type string length will be ;)

I do not care much about the 2G+ limit, as I said already multiple
times it is a side effect of this patch, not a goal.

Same for class names which shouldn't be possible to be longer than 255.

255 is not enough, but yes, we do not even need 2G :)

Cheers,

Pierre

@pierrejoye | http://www.libgd.org