开发者

SplFixedArray::fromArray - memory efficient as native fixed Array? PHP 5.3.5

开发者 https://www.devze.com 2023-03-13 19:15 出处:网络
I\'m experimenting with SplFixedArray. I have some work done with dynamic arrays which i\'m trying to convert to more memory efficient fixed arrays (limited RAM to work with).

I'm experimenting with SplFixedArray. I have some work done with dynamic arrays which i'm trying to convert to more memory efficient fixed arrays (limited RAM to work with).

Reading some PHP documentation, found the function in the Title and proceeded to just apply to an array which is like:

$array[x][y]['field']

(3d array with string as index, impossible in fixed arrays) by doing

$testArray =  SplFixedArray::fromArray(generateArray(256)); 
// generateArray is a function to create the array and set it to zero.

I checked if i could get some memory savings from this versus standard array and no. Replaced the string index with numbers, same amount of ram used (94 mb) to generate the array.

If i use SplFixedArray properly (not converting from an existing array) i low the mem used to 74mb, but i have a lot of functions and rutines which works with the base 3d array and would be a pain in the ass to convert everything 开发者_开发知识库to "proper" fixed array. That's why when i read abut SPL::fromArray i jumped on my chair. But with these tests, i found ZERO memory nor speed benefits.

Am i not using it correctly? Is this function just for other type of things?

Thanks!


The short of it is that PHP is not designed to be working with such large data structures in a memory efficient manner. Nothing you do is going to change that. Trying to work PHP within a 256MB VPS is very difficult, especially if you've got a web server and database server.

As I illustrated in your other question, SplFixedArrays use less memory. That's a fact, and you can look up in the PHP source to see how the objects are created. The numbers don't lie.

But it's only one piece of the puzzle... If you are storing lots of big things in the array or are working with other data structures, it's possible that the array isn't the "bottleneck" of memory usage.

Regarding SplFixedArray::fromArray(), you will definitely be adding to your peak usage, because you are now creating two array structures. If you delete the temporary array, you will then be using less memory... but in the interim, you'll be using more.

You'd probably use less peak memory if you just wrote your own function that shifted off an element of the temporary array one by one and added it to the SplFixedArray, as you wouldn't be duplicating your data structure size. (Due to copy-on-write, the actual savings may not be that big.)

Again, some benchmarks of 1024*1024 sized array with 64-bit integers in each slot:

SplFixedArray:            92,914,280
array:                   218,756,976
SplFixedArray::fromArray 227,147,408 peak, 92,915,088 after

So as you see, if you load fromArray, you are using more memory, but after the temporary array is deleted, it's back to the savings. But since the goal is to minimize peak memory usage, using fromArray will be worse than simply using arrays.


My experience is that most of the Spl classes are not real improvements over the native array performance wise. At best the tests prove inconclusive, at worse, they show the Spl libraries to be slower.

The major benefits? They are more reliable and consistent objects than array. SplFixedArray gives you the benefit of knowing that the indexes are ints (numeric indexes, I believe, actually are faster than string indexes), and that you can specifically set the length -- a major bonus if you have no idea how you ended up with some bizarro extra value.


I ran some tests on it as well. There seems to be no point in using SplFixedArray::fromArray. The memory savings is hardly noticeable.

0

精彩评论

暂无评论...
验证码 换一张
取 消