Actually, I just updated Rasmus' demo program to use assocative arrays
instead of objects.
In PHP 5.4.x, the associative array version uses more memory than the
object oriented version.
That's because PHP 5.4.x is using a flat array for predeclared
properties, as was mentioned earlier by
I just realized something that never occurred to me before - every
property is actually stored as a hash.
This test-script will demonstrate:
?php
define('NUM_TESTS', 1000);
$before = memory_get_usage(true);
$test = array();
class Foo
{
public
Hi!
How come it's necessary to store the property-names of every property
in every object? For properties that have been defined in classes, why
can't they be stored in a more efficient manner? (using lookup tables)
No because you can add and remove properties freely at runtime.
I know the
Yeah, dynamic properties get used by default every time you
json_decode something, to take a random example.
String folding could be used, but that would require a hashtable
lookup and would probably be slower than allocation (at least until
you started to swap). Worth testing maybe.
Or... when
On Mon, 21 May 2012 20:47:51 +0200, Rasmus Schultz ras...@mindplay.dk
wrote:
I just realized something that never occurred to me before - every
property is actually stored as a hash.
This test-script will demonstrate:
[snip]
The test-script contains no information about the version of
Thanks for clarifying that. Sounds like a huge win.
On Mon, May 21, 2012 at 3:13 PM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote:
On Mon, 21 May 2012 20:47:51 +0200, Rasmus Schultz ras...@mindplay.dk
wrote:
I just realized something that never occurred to me before - every
property is
I ran this script on 5.3.13, and it reported:
786432 bytes used
On 5.4.3, it reported:
262144 bytes used
That is definitely a significant improvement.
Objects are still a lot bigger than their contents. I don't expect
they would ever shrink to the size of their contents exactly or even
all
Hi!
262144 bytes used
That is definitely a significant improvement.
Objects are still a lot bigger than their contents. I don't expect
they would ever shrink to the size of their contents exactly or even
all that close of course.
Hashtables and zvals have overhead. So if you store
Adding/removing properties at runtime is great if you want obscure,
unmaintainable code and don't think an IDE is useful.
So to make my previous statement more precise, dynamic properties are
not widely used in respectable modern codebases, and is generally
something a reputable developer would
Rasmus, isn't your concern about the impact of dynamic property
support on developers who don't actually use it a nonissue in 5.4,
where properties that aren't dynamic are stored as a flat array?
On Mon, May 21, 2012 at 4:52 PM, Rasmus Schultz ras...@mindplay.dk wrote:
Adding/removing properties
What about a magic interface instead of a new base class, in a similar
vein to the existing Array Access and Serializable interfaces.
NonDynamic perhaps?
On Mon, May 21, 2012 at 5:09 PM, Tom Boutell t...@punkave.com wrote:
Rasmus, isn't your concern about the impact of dynamic property
support
No offense intended, but if you've got so many OOP objects flying
around that they are sucking down that much memory...
You probably need to refactor your code and just don't do that
Just my opinion.
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
12 matches
Mail list logo
