You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Data structures, or special versions of them, should be able to be written to a memory buffer in such a way that they can be loaded from there using a regular pointer cast (that is, without an explicit deserialization stage). This will allow them to be built at compile-time, embedding the preprocessed contents directly into the program executable file to reduce loading time.
It is important to note that this does not apply to loading from files or retrieving over the network due to endianness considerations and other architectural peculiarities on different machines. This requires full-fledged serialization, which goes beyond the scope of the library itself and thus must be implemented separately (that's why internals are exposed here).
Some quick and important observations that should be explored in more detail later:
Implicit data structures and open addressing. One of the clear problems raised here is how nodes should reference each other in a way that is efficient and does not require post-processing when loading and/or saving. Using absolute addresses implies either a fixed memory address at load time, or the use of relocations - both of which are insane and lead to an excessive dependence on the linker. Therefore, so far it looks like some kind of mechanism with pool allocation and relative addressing from the node or the pool itself.
Immutable vs mutable. For example, a mutable binary tree stored in an array requires a layout of $2^n - 1$ elements (where $n$ is the height) to be always allocated, even if it is sparse and many nodes simply do not exist. But this is not necessary for an immutable tree.
Data structures, or special versions of them, should be able to be written to a memory buffer in such a way that they can be loaded from there using a regular pointer cast (that is, without an explicit deserialization stage). This will allow them to be built at compile-time, embedding the preprocessed contents directly into the program executable file to reduce loading time.
It is important to note that this does not apply to loading from files or retrieving over the network due to endianness considerations and other architectural peculiarities on different machines. This requires full-fledged serialization, which goes beyond the scope of the library itself and thus must be implemented separately (that's why internals are exposed here).
Some quick and important observations that should be explored in more detail later:
Implicit data structures and open addressing. One of the clear problems raised here is how nodes should reference each other in a way that is efficient and does not require post-processing when loading and/or saving. Using absolute addresses implies either a fixed memory address at load time, or the use of relocations - both of which are insane and lead to an excessive dependence on the linker. Therefore, so far it looks like some kind of mechanism with pool allocation and relative addressing from the node or the pool itself.
Immutable vs mutable. For example, a mutable binary tree stored in an array requires a layout of$2^n - 1$ elements (where $n$ is the height) to be always allocated, even if it is sparse and many nodes simply do not exist. But this is not necessary for an immutable tree.
https://30fps.net/pages/clean-pointer-serialization/
The text was updated successfully, but these errors were encountered: