> On Sep 16, 2021, at 10:09 PM, tyson andre <tysonandre...@hotmail.com> wrote: > > Hi internals, > > I've created a new RFC https://wiki.php.net/rfc/vector proposing to add > `final class Vector` to PHP. > > PHP's native `array` type is rare among programming language in that it is > used as an associative map of values, but also needs to support lists of > values. > In order to support both use cases while also providing a consistent internal > array HashTable API to the PHP's internals and PECLs, additional memory is > needed to track keys > (https://www.npopov.com/2014/12/22/PHPs-new-hashtable-implementation.html - > around twice as much as is needed to just store the values due to needing > space both for the string pointer and int key in a Bucket, for non-reference > counted values)). > Additionally, creating non-constant arrays will allocate space for at least 8 > elements to make the initial resizing more efficient, potentially wasting > memory. > > It would be useful to have an efficient variable-length container in the > standard library for the following reasons: > > 1. To save memory in applications or libraries that may need to store many > lists of values and/or run as a CLI or embedded process for long periods of > time > (in modules identified as using the most memory or potentially exceeding > memory limits in the worst case) > (both in userland and in native code written in php-src/PECLs) > 2. To provide a better alternative to `ArrayObject` and `SplFixedArray` for > use cases > where objects are easier to use than arrays - e.g. variable sized > collections (For lists of values) that can be passed by value to be read and > modified. > 3. To give users the option of stronger runtime guarantees that property, > parameter, or return values really contain a list of values without gaps, > that array modifications don't introduce gaps or unexpected indexes, etc. > > Thoughts on Vector?
Given there seems to be a lot of concern about the approach the RFC proposes would it not address the concerns about memory usage and performance if several methods were added to SplFixedArray instead (as well as functions like indexOf(), contains(), map(), filter(), JSONSerialize(), etc., or similar): =============== setCapacity(int) — Sets the Capacity, i.e. the maximum Size before resize getCapacity():int — Gets the current Capacity. setGrowthFactor(float) — Sets the Growth Factor for push(). Defaults to 2 getGrowthFactor():float — Gets the current Growth Factor pop([shrink]):mixed — Returns [Size] then subtracts 1 from Size. If (bool)shrink passed then call shrink(). push(mixed) — Sets [Size]=mixed, then Size++, unless Size=Capacity then setSize(n) where n=round(Size*GrowthFactor,0) before Size++. grow([new_capacity]) — Increases memory allocated. Sets Capacity to Size*GrowthFactor or new_capacity. shrink([new_capacity]) — Reduces memory allocated. Sets Capacity to current Size or new_capacity. =============== If you had these methods then I think you would get the memory and performance improvements you want, and if you really want a final Vector class for your own uses you could roll your own using inheritance or containment. Would this not work? -Mike P.S. I also think asking for new methods on SplFixedArray has a much greater chance of successful than an RFC for Vector. #jmtcw -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
