As in Xojo, Objo arrays aren't really arrays in the standard sense of a fixed size, typically with values or object pointers contiguous in memory. They seem more like .NET List<T>, with the ability to insert, remove, append, etc.

In fact since this is running on .NET Core I wouldn't be surprised if they actually ARE List<T>s under the hood.

If so, sometimes it's a VERY useful performance enhancement to presize the collection when you have some idea of its expected size. I was reminded of this today:

https://www.linkedin.com/blog/engineering/feed/the-58-million-key-freeze-what-a-hashmap-resize-taught-us-about-memory-allocation-at-scale

The link is to a lot of paragraphs evaluating to a one line fix for a nearly minute long system-wide freeze -- pre-allocate a dictionary in this case so it doesn't reorganize itself at runtime.

Anyway ... in .NET this is done at construction time along the lines of:

new List<string>(500);

And there is a Capacity property independent of Count so you know what the current tipping point is.
The backing array for the List<string> is initially empty, then is expanded to 4 when something is inserted, then 8, when you add the 5th item, 16, 32, etc. If you know you have a large # of items (or the typical use case will) then you can just avoid all those early reallocations.

The closest Objo currently comes to this that I can find is the Resize method, so the equivalent of the above would be:

var foo() as String = []
foo.Resize(500)

... although this is different from setting the capacity as it fills the array to that size, if I correctly understand the docs. So an Add() call after the above would add a 501st element. That is not exactly what I'm after.

It's possible that I'm barking up the wrong tree and there are no allocation or perf issues here as the internal mechanisms are different than I assume.

Anyway if I'm on the right track: If the backing store is initially empty or quite small, this is probably fine from a performance standpoint. It would be nice to have a convenience constructor overload that would take an initial size, as IMO it would encourage more awareness of this issue, plus it would allow the runtime to immediately size the backing store, which I assume would be a slight perf enhancement at least indirectly by avoiding a runtime reallocation. So something like:

var foo(500) As String # array of 500 null strings (okay, nothing strings)
var foo(500) As String = "" # array of 500 empty strings

Honestly it seems like every time I specify the initial Capacity when creating lists in C# code, reviewers are encountering it for the very first time, so I suspect there are needless allocations in many code bases.

Maybe the ethos of a BASIC dialect is not to clutter people's minds with these considerations so long as there's a mechanism (Resize in this case) to deal with it when you're more advanced, IDK. Just a thought.

ETA: Where I'm thinking of going with this is to inherit or put a thin wrapper around Array to effectively track Count and Capacity separately and intercept Add() calls to work properly with the "virtual tail" of the collection. Of course my dream would be a Capacity property for arrays so I wouldn't have to do this myself.