linksplatform / linksplatform/Data.Doublets

UnitedRangedMemoryLinks that will support ranges for binary data

Open
#512 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

documentation enhancement
Dominant language
C#
Stars
14
Forks
5
PR merge metrics
No merged PRs in 30d

Description

Add version of `csharp/Platform.Data.Doublets/Memory/United` (UnitedMemoryLinks), that will track unused links not in linked list, but linked list of ranges. We need elegant solution, that will allow us to allocate/deallocate ranges that are multiple of single link size, so the memory management is still uniform without possibility of any fragmentation, but now we should also be to allocate/deallocate ranges of links (that should be faster than allocating one by one), and also allocating raw binary ranges. And use some constant in LinksContants as a marker of such raw binary links (that are not doublets any more, but a continuous sequence of TLinkAddress, that should be treated not as references to links, but binary data itself). Also in binary range the fields we usually used for indexing trees should be supported as just continuation of binary data, we should record marker + length of the sequence in multiples of TLinkAddress, so from it we also calculate the range in number of links (where each link as it takes 8 of TLinkAddress).

So we add new UnitedRanged folder, and do not break any other existing feature, and also add fully supported in all places UnitedRangedMemoryLinks, that can be used as substitution of UnitedMemoryLinks.

So the end result should be like this - we should be able to store in our datastore not only links, but also raw binary data, that can be used for any purpose we like. And all space between raw binary data block will be filled with links, if we have unused or deleted range of links inside the used data, and it is enough for requested binary range, we should use it from there, so we prefer filling the empty / unused space, to pack up everything nicely. And yet, we should never allow fragmentation, meaning if the size of requested range is greater than any free range, we should just append it to the end of the data store.

We need to collect data related about the issue to this repository, make sure we compile that data to `./docs/case-studies/issue-{id}` folder, and use it to do deep case study analysis (also make sure to search online for additional facts and data), list of each and all requirements from the issue, and propose possible solutions and solution plans for each requirement (we should also check known existing components/libraries, that solve similar problem or can help in solutions).

Please plan and execute everything in a single pull request, you have unlimited time and context, as context auto-compacts and you can continue indefinitely, until it is each and every requirement fully addressed, and everything is totally done.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading csharp/Platform.Data.Doublets/Memory/United and the existing UnitedMemoryLinks implementation, then inspect LinksContants and the repository’s integration points. The work is done only when UnitedRangedMemoryLinks supports ranged link and raw binary allocation without breaking existing behavior, is usable as a UnitedMemoryLinks substitute, and the requested case-study material is compiled under ./docs/case-studies/issue-512.

Written by the indexing model from the issue text.

Assessment

Tech stack
csharp
Domain
databases
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.