@ Anyone? I have a cursor for directbytebuffers...

# stdlib

[jimn]

@ Anyone?
I have a cursor for directbytebuffers.

this cursor randomly seeks to mmap backingstore offsets and performs a functor over n fields to map them positionally into the graph of idempotent program state.

there are composable Unary operators applied to these idempotent rows.

the abstraction i chose first was Array<Array<Any?>> naively to see how it worked out, which works up to a certain number of rows and then kills the jvm heap

in order to support a future definition of easily parralellizable streaming i went with Array<Flow<Any?>> so that in thoery my idempotent state is only as expensive as decoder access in time/memory.

this works up to a certain number of rows and then kills the jvm heap. but that number is a bit lower than i predicted. this also introduced a boundary of suspend on functions i didn't previously have making certain operators less extendable.

i have produced a little taxonomy of vectorlike types and operations. i call it keyboard practice in jest, and while it may overlap the stdlib it seems like this file addresses the containment of spread operator copies when using varargs, and not using varargs makes excessive keyboard practice. i digress -- this is a list of candidate idemoptent mementos of iterator state for mmap backed directbytebuffers.

https://github.com/jnorthrup/columnar/blob/a90f816460fa2390a527d65f0238310aee168034/src/main/kotlin/columnar/VectorLike.kt

so the question... sorry for such a lengthy prelude, is "does suspend and thereafter Flow induce extra inlining and extra captured state when composing deeply with Unary Operators (Function1<T,T>)" ?

among the "Vector-like" type options is there going to be a stack reference retention to parent state that is less duplicated by hot options than by cold options?