Tim Starling wrote:
> For Mr. "everyone has 8GB of memory and tiny little data sets" Lerdorf,
> I could point out that reducing the average zend_op size and placing
> strings close to other op data will also make execution faster, due to
> the improved CPU cache hit rate.
Nice twist there. I simp
Stanislav Malyshev wrote:
>
> opcodes can be cached (bytecode caches do it) but op_array can't
> really be cached between requests because it contains dynamic
> structures. Unlike Java, PHP does full cleanup after each request,
> which means no preserving dynamic data.
APC deep-copies the whole ze
Hi!
class C {
var $v1, $v2, $v3, $v4, $v5, $v6, $v7, $v8, $v9, $v10;
}
$m = memory_get_usage();
$a = array();
for ( $i = 0; $i< 1; $i++ ) {
$a[] = new C;
}
print ((memory_get_usage() - $m) / 1) . "\n";
?>
1927 bytes (I'll use 64-bit from now on since it gives the most shocki
Tim Starling wrote:
> class C {
> var $v1, $v2, $v3, $v4, $v5, $v6, $v7, $v8, $v9, $v10;
> }
>
> $m = memory_get_usage();
> $a = array();
> for ( $i = 0; $i < 1; $i++ ) {
> $a[] = new C;
> }
> print ((memory_get_usage() - $m) / 1) . "\n";
> ?>
>
> 1927 bytes (I'll use 64-bit from
Tim Starling wrote:
> Some other operations, like deleting items from the middle of the array
> or adding items past the end (leaving gaps) would also have to trigger
> conversion. The point would be to optimise the most common use cases for
> integer-indexed arrays.
I still say this isn't somethi
Stanislav Malyshev wrote:
> Hi!
>
>> > $m = memory_get_usage();
>> $a = explode(',', str_repeat(',', 10));
>> print (memory_get_usage() - $m)/10;
>
> Says 93.2482 for me. Should be even less since string generated by
> str_repead itself also is counted as overhead (without it it's
> 92.2474
Stanislav Malyshev wrote:
> Hi!
>
>> Says 93.2482 for me. Should be even less since string generated by
>
> On 64-bit I get about 170 bytes for 5.2, don't have 5.3 build handy on
> 64-bit.
178.4972 5.3 non-debug 64-bit Linux
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To u
On Wed, 13 Jan 2010, Stanislav Malyshev wrote:
> > Says 93.2482 for me. Should be even less since string generated by
>
> On 64-bit I get about 170 bytes for 5.2, don't have 5.3 build handy on 64-bit.
On 64bit (debug builds):
der...@kossu:~$ pe 5.3dev
der...@kossu:~$ php
378.54448
der...@kos
Hey list:
I noticed an issue today running our ZF unit tests, it primarily came
down to this issue:
On 32 bit environments ..
~# php -r "var_dump(PHP_INT_MAX+1 > PHP_INT_MAX);"
.. will return true, whereas in 64bit environments, this returns false.
In talking with Stas, it seems that since
Hi!
Says 93.2482 for me. Should be even less since string generated by
On 64-bit I get about 170 bytes for 5.2, don't have 5.3 build handy on
64-bit.
--
Stanislav Malyshev, Zend Software Architect
s...@zend.com http://www.zend.com/
(408)253-8829 MSN: s...@zend.com
--
PHP Internals - PHP
On Thu, Jan 14, 2010 at 1:16 AM, Stanislav Malyshev wrote:
> Hi!
>
>> It makes no difference between PECL and core. Unlike the main
>> extension page, the filters do not containt the PECL section/notice.
>> SSH2 is another example of this problem.
>
> Yes, but the problem is people actually instal
Hi!
It makes no difference between PECL and core. Unlike the main
extension page, the filters do not containt the PECL section/notice.
SSH2 is another example of this problem.
Yes, but the problem is people actually install mcrypt (which is in
source so everybody supposed to have it) and expe
On Thu, 14 Jan 2010, Tim Starling wrote:
> * Exposing strongly-typed list and vector data structures to the user,
> that don't have massive hashtable overheads
I'm actually working on a few things here.. some more efficient sets and
hashes. Expect more to see soon.
regards,
Derick
--
http://d
Tim Starling wrote:
> Rasmus Lerdorf wrote:
>> For me, working in super high-load environments, this was never an issue
>> because memory was always way more plentiful than cpu. You can only
>> slice a cpu in so many slices. Even if you could run 1024 concurrent
>> Apache/PHP processes, you would
On Wed, Jan 13, 2010 at 11:48 PM, Stanislav Malyshev wrote:
> Hi!
>
> We have mcrypt streams documented here:
> http://www.php.net/manual/en/filters.encryption.php
> however contrary to what the manual says, I do not see any implementation of
> mcrypt.* filters in mcrypt extension. There's some co
Help!
I was patching out a new version of my PHP extension, with a different version
as part of the name:
libmyext.so.1.0 is now libmyext.so.2.0
I updated php.ini (extension=libmyext.so.2.0) and restarted apache with the
graceful option. For some reason, both extensions were loaded simultane
Hi!
Says 93.2482 for me. Should be even less since string generated by
str_repead itself also is counted as overhead (without it it's 92.2474).
Aren't you perchance using debug build? Debug build gives 196 for me.
--
Stanislav Malyshev, Zend Software Architect
s...@zend.com http://www.zen
Hi!
Given this, sometimes it's easy to forget that PHP is pathologically
memory hungry, to the point of making simple tasks difficult or
impossible to perform in limited environments. It's the worst language
I've ever encountered in this respect. An array of small strings will
use on the order o
Rasmus Lerdorf wrote:
> Tim Starling wrote:
>
>> Given this, sometimes it's easy to forget that PHP is pathologically
>> memory hungry, to the point of making simple tasks difficult or
>> impossible to perform in limited environments. It's the worst language
>> I've ever encountered in this resp
Hi!
We have mcrypt streams documented here:
http://www.php.net/manual/en/filters.encryption.php
however contrary to what the manual says, I do not see any
implementation of mcrypt.* filters in mcrypt extension. There's some
code in PECL mcrypt_filters extension, which is never mentioned in the
Hi Raphael:
> What patch do you want to know more about?
None. I am wondering if there is a resource for lay-people interested in
installing PHP via packages so they can know any eccentricities they will
encounter when compared to compiling it themselves.
For example, you discussed changing s
Raphael Geissert wrote:
> Rasmus Lerdorf wrote:
>
>> Raphael Geissert wrote:
>>> However, we would like to contribute in the quest to make applications
>>> stop using short_open_tag. To do so, we have decided to throw an
>>> E_DEPRECATED warning when an application makes use of short_open_tag. The
Rasmus Lerdorf wrote:
> Raphael Geissert wrote:
>> However, we would like to contribute in the quest to make applications
>> stop using short_open_tag. To do so, we have decided to throw an
>> E_DEPRECATED warning when an application makes use of short_open_tag. The
>> current implementation can b
Daniel Convissor wrote:
> Hi Raphael:
>
> On Tue, Jan 12, 2010 at 02:48:38PM -0600, Raphael Geissert wrote:
>> As a first step I'll be trying to forward most of our
>> patches so that there's a minor divergence.
>
> Is there a document somewhere that explains the changes the Debian team
> has ma
Alain Williams wrote:
> On Wed, Jan 13, 2010 at 07:48:17AM -0800, Rasmus Lerdorf wrote:
>> Alain Williams wrote:
>
>>> Unfortunately: APC does not work with PHP 5.3 -- I have a site where I would
>>> love to use it but I cannot. I use APC to great effect elsewhere.
>> The svn version works ok with
Tim Starling wrote:
> Given this, sometimes it's easy to forget that PHP is pathologically
> memory hungry, to the point of making simple tasks difficult or
> impossible to perform in limited environments. It's the worst language
> I've ever encountered in this respect. An array of small strings wi
Johannes Schlüter wrote:
> Hi,
>
> On Tue, 2010-01-12 at 14:48 -0600, Raphael Geissert wrote:
>> Hello,
>>
>> At Debian we are planning to include PHP 5.3 in Squeeze, the next stable
>> release. As such, I would like to know for example when we could expect
>> 5.3.2 and 5.3.3 to be released.
>
On Wed, Jan 13, 2010 at 07:48:17AM -0800, Rasmus Lerdorf wrote:
> Alain Williams wrote:
> > Unfortunately: APC does not work with PHP 5.3 -- I have a site where I would
> > love to use it but I cannot. I use APC to great effect elsewhere.
>
> The svn version works ok with 5.3. Turn off gc though
2010/1/13 Rasmus Lerdorf :
> Richard Quadling wrote:
>> Hello.
>>
>> In looking at numer vs string comparison, I think I've found an oddity.
>>
>> You can successfully compare hex strings ...
>>
>> var_dump(255 == '0xff');
>>
>> but not octal strings ...
>>
>> var_dump(63 == '077');
>>
>>
>> Is thi
Richard Quadling wrote:
> Hello.
>
> In looking at numer vs string comparison, I think I've found an oddity.
>
> You can successfully compare hex strings ...
>
> var_dump(255 == '0xff');
>
> but not octal strings ...
>
> var_dump(63 == '077');
>
>
> Is this a bug (lack of octal support) or a
2010/1/13 hack988 hack988 :
> I think it's not an but!
> you must read carefuly about "Single quoted" and "Double quoted"
>
> 2010/1/14 Richard Quadling :
>> Hello.
>>
>> In looking at numer vs string comparison, I think I've found an oddity.
>>
>> You can successfully compare hex strings ...
>>
>>
I think it's not an but!
you must read carefuly about "Single quoted" and "Double quoted"
2010/1/14 Richard Quadling :
> Hello.
>
> In looking at numer vs string comparison, I think I've found an oddity.
>
> You can successfully compare hex strings ...
>
> var_dump(255 == '0xff');
>
> but not octa
Alexey Zakhlestin wrote:
>
> Great news!
> Does it mean, that 5.3 will move to "unstable" branch soon?
> (currently, Debian has 5.3 only in "testing")
>
It is currently in "experimental," but yes, we will soon be uploading it to
unstable so that it later migrates to testing.
Cheers,
--
Rapha
Graham Kelly wrote:
> Overall though, more often than not PHP is not the bottleneck of your
> program and thus optimization wont get you too much.
In a lot of ways, PHP is already well-optimised. The hash tables are
fast, the executor is decent, as executors for weakly-typed languages
go. Many int
Hello.
In looking at numer vs string comparison, I think I've found an oddity.
You can successfully compare hex strings ...
var_dump(255 == '0xff');
but not octal strings ...
var_dump(63 == '077');
Is this a bug (lack of octal support) or an unexpected feature (hex support)?
Neither format
Alain Williams wrote:
> On Wed, Jan 13, 2010 at 10:25:01AM -0500, Graham Kelly wrote:
>> Hi,
>>
>> Optimizations such as 5+7 into 13 really don't get you much. ZEND_ADD (and
>> other basic opcodes) are not in any way a slow point in a program. And
>> unfortunately to be able to optimize these you w
Hi Raphael:
On Tue, Jan 12, 2010 at 02:48:38PM -0600, Raphael Geissert wrote:
> As a first step I'll be trying to forward most of our
> patches so that there's a minor divergence.
Is there a document somewhere that explains the changes the Debian team
has made? (Other than reading a 600 kb dif
On Wed, Jan 13, 2010 at 10:25:01AM -0500, Graham Kelly wrote:
> Hi,
>
> Optimizations such as 5+7 into 13 really don't get you much. ZEND_ADD (and
> other basic opcodes) are not in any way a slow point in a program. And
> unfortunately to be able to optimize these you would probably need to put in
Hi,
Optimizations such as 5+7 into 13 really don't get you much. ZEND_ADD (and
other basic opcodes) are not in any way a slow point in a program. And
unfortunately to be able to optimize these you would probably need to put in
an extra pass in the compiler which would probably just slow things dow
Etienne Kneuss wrote:
Hello,
On Wed, Jan 13, 2010 at 2:36 PM, mathieu.suen
wrote:
Hi,
I came across this:
echo sizeof(array());
echo sizeof("");
$a = "";
php.net/count:
"If var is not an array or an object with implemented Countable
interface, 1 will be returned. There is one excep
var_dump((array)"");
Results in:
array(1) {
[0]=>
string(0) ""
}
And 'array("")' is not empty.
-- Jille
Op 13-1-2010 14:50, Etienne Kneuss schreef:
Hello,
On Wed, Jan 13, 2010 at 2:36 PM, mathieu.suen
wrote:
Hi,
I came across this:
echo sizeof(array());
echo sizeof("");
$a =
Hi,
On Tue, 2010-01-12 at 14:48 -0600, Raphael Geissert wrote:
> Hello,
>
> At Debian we are planning to include PHP 5.3 in Squeeze, the next stable
> release. As such, I would like to know for example when we could expect
> 5.3.2 and 5.3.3 to be released.
I hope that the new release branch me
mathieu.suen wrote:
Sebastian Bergmann wrote:
Am 13.01.2010 12:18, schrieb mathieu.suen:
Because any optimization, even very simple ones, impose a performance
penalty in the default execution model of PHP which does not use a
bytecode cache.
For simple optimization I don't think so.
Hello,
On Wed, Jan 13, 2010 at 2:36 PM, mathieu.suen
wrote:
> Hi,
>
> I came across this:
>
> echo sizeof(array());
> echo sizeof("");
> $a = "";
php.net/count:
"If var is not an array or an object with implemented Countable
interface, 1 will be returned. There is one exception, if var is NULL,
Hi,
I came across this:
echo sizeof(array());
echo sizeof("");
$a = "";
var_dump( empty($a));
$a = array();
var_dump(empty($a));
So funny! How something can have a size greater than 0 but still be empty?
I think PHP is reinventing the inconsistency word.
But then let assume that empty is just
Etienne Kneuss wrote:
Hello,
On Tue, Jan 12, 2010 at 11:40 PM, Chris Stockton
wrote:
Hello,
On Mon, Jan 11, 2010 at 8:32 PM, mm w <0xcafef...@gmail.com> wrote:
cast is not needed in PHP
i 'd rather be more interesting in
class Obj {
function __catch($data, $type) {
//$type
On 01/12/2010 10:48 PM, Raphael Geissert wrote:
Hello,
At Debian we are planning to include PHP 5.3 in Squeeze, the next stable
release. As such, I would like to know for example when we could expect
5.3.2 and 5.3.3 to be released.
Wouldn't we all. Haven't seen any merges to the release branch
Sebastian Bergmann wrote:
Am 13.01.2010 12:18, schrieb mathieu.suen:
I would like to know why the opcode is not optimized.
Because any optimization, even very simple ones, impose a performance
penalty in the default execution model of PHP which does not use a
bytecode cache.
the path is like unstable -> testing -> stable
so the testing will be the new stable.
http://en.wikipedia.org/wiki/File:Debian-package-cycle.png
Tyrael
On Wed, Jan 13, 2010 at 11:00 AM, Alexey Zakhlestin wrote:
>
> On 12.01.2010, at 23:48, Raphael Geissert wrote:
>
>> Hello,
>>
>> At Debian we a
Am 13.01.2010 12:18, schrieb mathieu.suen:
> I would like to know why the opcode is not optimized.
Because any optimization, even very simple ones, impose a performance
penalty in the default execution model of PHP which does not use a
bytecode cache.
Only when the bytecode is not regenerated
Hi,
I would like to know why the opcode is not optimized. Even for some very
simple optimization like constant folding.
For exemple:
line # op fetch ext return
operands
---
On Tue, 12 Jan 2010, Raphael Geissert wrote:
> As mentioned on my other post, at Debian we are planning to include
> 5.3 in Squeeze. Given that the development and production php.ini
> files both turn short_open_tag by default but many applications
> shipped by Debian itself still require it to
It appears that, mm w is talking about some aspect oriented feature.
I would welcome a magic method that would intercept calls/access to
existing methods/properties (not only inaccessible ones), in the same
sense that __getattribute__ works in Python for example IIRC. It may
also be a good tim
Hello,
On Tue, Jan 12, 2010 at 11:40 PM, Chris Stockton
wrote:
> Hello,
>
> On Mon, Jan 11, 2010 at 8:32 PM, mm w <0xcafef...@gmail.com> wrote:
>> cast is not needed in PHP
>>
>> i 'd rather be more interesting in
>>
>> class Obj {
>> function __catch($data, $type) {
>> //$type [ s
On 12.01.2010, at 23:48, Raphael Geissert wrote:
> Hello,
>
> At Debian we are planning to include PHP 5.3 in Squeeze, the next stable
> release. As such, I would like to know for example when we could expect
> 5.3.2 and 5.3.3 to be released.
Great news!
Does it mean, that 5.3 will move to "u
55 matches
Mail list logo
