Memory duplication when using slice

[cdlscpmv]

I've noticed that calling slice on an array or tuple causes new memory to be allocated for the returned tuple. This may cause some performance penalty when working with big data sets.

Since the returned tuple is read-only, is it possible to reuse the existing memory for it instead of making a copy, or this would require some big changes in the Janet VM?

[pepe]

It may be just me, but I am using it sometimes just for that feature (slice arr) to create a new array or tuple.

[bakpakin]

It would require larger changes - we would need to introduce a new type internally. I suppose some kind of view type, or implementing Copy on Write for arrays and tuples would make some sense, but I don't think it could easily be done without changing the C API.

A new View type would probably be the easiest way to do this.

[cdlscpmv]

I see. But what about converting arrays to tuples without making a copy, that is, in place, just like sort works? I often times find myself creating an array inside a function and then convert it to a tuple at the very end to make it immutable.

Another usage scenario is that sometimes I prefer map, filter, etc. to return a tuple instead of an array, so that I don't accidentally modify it.

Perhaphs, a non-recursive, zero-copy version of freeze would be useful in such scenarios, although there is a slight problem with this approach:

(def arr @[1 2 3])
(def tup (freeze* arr))

Now the type of arr has to change to tuple also. I don't know in what way Janet traces references to objects, so it may not be the best approach.

If implementing the View type turns out to be more viable, then allowing it to work with tables in addition to arrays would be useful also.

[bakpakin]

Another usage scenario is that sometimes I prefer map, filter, etc. to return a tuple instead of an array, so that I don't accidentally modify it.

That seems like a separate ask, but could similarly be solved by making a custom type.

A "builder" api would be doable with the current API

(def builder (tuple/builder 100)) # provide initial buffer length guess
(each x (my-fancy-iterator)
  (tuple/builder-push builder x))
(def tup (tuple/builder-commit builder))

The call to tuple/builder-commit could not actually allocate any new memory, so would let us implement filter/map/seq to tuples without the extra copy.

Alternatively, just embrace arrays. The use-cases where tuples are much better than arrays in Janet are usually small tuples used as table keys. Using data that is so big that copying is a large concern, even in a scripting language like Janet, implies that we are probably not making table keys, which is the main use for tuples.

[cdlscpmv]

The "builder" API would solve some of the problems, but I think duplicating the array API isn't the cleanest approach. And it would require reimplementing many of the existing functions like map on top of this new API which, I think, is an overkill.

My main objective behind this proposition is to embrace the immutability approach, which I find quite useful in the absence of static typing, but without unnecessary performance penalty.

From the API perspective that would look something like this

(def arr @[])
(do-something-with-the-array ...)
(def tup (const arr))

Now the tup is a constant reference to arr through which arr cannot be modified. That's the idea behind the View type if I understood you correctly. But the operation of this View type should happen transparently for the user, that is, array becomes tuple, and table becomes struct.

Another approach is to introduce a new keyword similar to def and var

(const tup arr)

[bakpakin]

Another approach is to introduce a new keyword similar to def and var

I don't see any reason to add a new special form.

The idea itself isn't bad, but there are some details that make it a little hairy to add:

• Converting arrays to tuples with no copying would need to add some Copy-on-Write logic to arrays or similar, and even then the C api lets users poke into an array and update elements as desired.
• Another issue is that internally, tuples and arrays aren't represented in quite the same way, so extra overhead would need to be added to how we represent arrays or tuples - tuples currently are in a single contiguous allocation, arrays are not.

Neither of these are impossible (or even that difficult) to overcome, but not without caveats.

[cdlscpmv]

I wonder how feasible it is to implement Copy-on-Write in Janet with the restriction that it happens on the memory page level (4 KB). Then even if arrays are not contiguous in memory, the underlying memory pages can be remapped into a contiguous area to represent tuples.

[sarna]

I often times find myself creating an array inside a function and then convert it to a tuple at the very end to make it immutable.

Alternatively, just embrace arrays. The use-cases where tuples are much better than arrays in Janet are usually small tuples used as table keys. Using data that is so big that copying is a large concern, even in a scripting language like Janet, implies that we are probably not making table keys, which is the main use for tuples.

I also struggle[d] with this. I thought that Janet would be better at this style where you modify data in-place - when it's safe - for readability/speed, but otherwise keep things mostly immutable. In practice many functions return the mutable collections, and every call to freeze is a full copy, so it's not as convenient and performant as I thought it'd be.

Embracing arrays sounds like the logical conclusion, but then you lose the strengths of immutable collections: no accidental modification, value semantics, fast equality, faster access (in theory, not sure if in practice). The equality in particular is painful, as in most cases all my big collections end up being mutable, so I need to compare them element-by-element. This makes me sad, as I hoped Janet would suit my style much better than Lua in this area, but in practice I end up with similar imperative code.

What I'm trying to say is, I'd greatly appreciate any mechanisms that'd make a "mostly immutable" style less painful in Janet. Copy-on-Write sounds nice.