On Mon, Mar 9, 2015 at 3:52 PM, Bob Weinand wrote:
> > Am 09.03.2015 um 11:24 schrieb Derick Rethans :
> >
> > On Fri, 27 Feb 2015, Xinchen Hui wrote:
> >
> >> Hey Internals:
> >>
> >> I was looking Bob's switch optimization..
> >>
> >> then I start to worry about where is the place opt
> Am 09.03.2015 um 11:24 schrieb Derick Rethans :
>
> On Fri, 27 Feb 2015, Xinchen Hui wrote:
>
>> Hey Internals:
>>
>> I was looking Bob's switch optimization..
>>
>> then I start to worry about where is the place optimization should
>> goes..
>>
>> in generally, PHP is a int
On Mar 9, 2015 1:24 PM, "Derick Rethans" wrote:
>
> On Fri, 27 Feb 2015, Xinchen Hui wrote:
>
> > Hey Internals:
> >
> > I was looking Bob's switch optimization..
> >
> > then I start to worry about where is the place optimization
should goes..
> >
> > in generally, PHP is a int
On Fri, 27 Feb 2015, Xinchen Hui wrote:
> Hey Internals:
>
> I was looking Bob's switch optimization..
>
> then I start to worry about where is the place optimization should
> goes..
>
> in generally, PHP is a interpreted language. IMO, it should
> compiler the PHP codes to
On Feb 27, 2015 5:23 PM, "Xinchen Hui" wrote:
>
> Hey Internals:
>
> I was looking Bob's switch optimization..
>
> then I start to worry about where is the place optimization should
goes..
>
> in generally, PHP is a interpreted language. IMO, it should
> compiler the PHP codes t
On Sat, Jan 30, 2010 at 9:37 PM, Richard Lynch wrote:
> On Sat, January 23, 2010 2:26 pm, steve wrote:
>> The guys at Zend muscled in to change the culture as well, and have
>
> I'm not sure that's a fair representation of the historical reality of
> how Zend came into existence...
OK. I don't th
The gc code when combined with apc is still a bit shaky in 5.3. I
haven't figured out why yet. And my motivation for figuring it out is
pretty low as code that relies on gc is slow.
-Rasmus
Motivation for relying on GC in 5.3 is pretty low because 5.3 is still a bit
shaky...
--
PHP Intern
On Sat, January 23, 2010 2:26 pm, steve wrote:
> The guys at Zend muscled in to change the culture as well, and have
I'm not sure that's a fair representation of the historical reality of
how Zend came into existence...
> succeeded to a large degree, pushing PHP into the enterprise by
> offering
Karsten Dambekalns wrote:
> Why is that advisable? Any pointers to background information welcome.
The gc code when combined with apc is still a bit shaky in 5.3. I
haven't figured out why yet. And my motivation for figuring it out is
pretty low as code that relies on gc is slow.
-Rasmus
--
Hi.
On 13.01.10 16:48, 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.
Hm. I have 5.3.1 with APC 3.1.3p1 and it runs fine. This is not a
production en
Just as a reference point should someone come across this thread at a
later date, and are interested in how memory usage changes
performance, this was one of the articles I found that does a decent
job, somewhat dated:
What every programmer should know about memory
http://lwn.net/Articles/250967/
> This isn't about server costs. It is about choosing the right tool for
> the right part of the job. A Javascript library for the client-side
> frontend, PHP for the server-side frontend, C/C++ for your middle-layer
> and an appropriate datastore behind it all and you can build amazing
> things
hi,
On Sat, Jan 23, 2010 at 9:26 PM, steve wrote:
>> But community members are developing those things nonetheless.
>> eAccelerator has an optimizer, there are several so-called byte code
>> caches, and Roadsend is a promising compiler project.
>
> Have been developing for a more than a decade..
Tim Starling wrote:
> That's not the world I live in. I work on a pure-PHP application which
> is widely used on servers where the installing user does not have the
> ability to change their php.ini or to install extensions or middleware.
> The same application (with a few small extensions in C/C++
steve wrote:
> Like a founder of a company that sets the corporate culture, don't
> count Rasmus out so easily. Founders earn such power. Until they are
> booted. It is not going to, nor should it, happen here.
I don't think PHP has an Ulrich Drepper or a Linus Torvalds. When I read
this list, I s
I think some of this discussion has been from very different interesting
angles. Let me explain how I see and use PHP.
PHP is the frontend of your backend. It is not your backend in any
sizable system. By that I mean that PHP is not the place to play around
with large data sets. Databases, Cas
>> I doubt anyone does I1/D1/L2 cache profiling for PHP.
>
> I did a little bit of CPU cache profiling of PHP using oprofile, more
> out of curiosity than anything. It was a couple of years ago now.
>
> http://wikitech.wikimedia.org/view/Oprofile
>
> But you don't need oprofile, you can make change
steve wrote:
>
> I don't think PHP has as much support as you think it does. There is
> no big supporter to fund a real development drive like that.
I'd like to think that I've more or less worked out who supports PHP by
now. I know I don't go to many conferences but I haven't been living in
a ca
steve wrote:
>> Having 8 cores with only 1G of ram would be a weird server config.
>
> A single socket quad-core with hyper-threading and 2GB RAM for a
> 32-bit webserver is not weird. Not everyone is Yahoo where you can
> just throw money around.
Hyperthreading doesn't come anywhere near making
> Having 8 cores with only 1G of ram would be a weird server config.
A single socket quad-core with hyper-threading and 2GB RAM for a
32-bit webserver is not weird. Not everyone is Yahoo where you can
just throw money around.
> For Mr. "everyone has 8GB of memory and tiny little data sets" Lerdor
> -Original Message-
> From: Tim Starling [mailto:tstarl...@wikimedia.org]
> Sent: Wednesday, January 13, 2010 7:19 PM
> To: Stas Malyshev
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] About optimization
>
> Stanislav Malyshev wrote:
> >
> > op
Hi!
Basically a structure like the current zend_op_array would be created on
demand by the executor instead of in advance by the compiler.
I guess we could have strings, etc. put in one big string buffer and
refer to them by 32-bit index, that would probably work with statically
allocated th
Rasmus Lerdorf wrote:
Tim Starling wrote:
1927 bytes (I'll use 64-bit from now on since it gives the most shocking
numbers)
PHP 5.3.3-dev (cli) (built: Jan 11 2010 11:26:25)
Linux colo 2.6.31-1-amd64 #1 SMP Sat Oct 24 17:50:31 UTC 2009 x86_64
php > class C {
php { var $v1, $v2, $v3, $v4
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
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, 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
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
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
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
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
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
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
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.
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.
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
47 matches
Mail list logo
