Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for "capacity" #1

Open
davidberneda opened this issue Jun 15, 2015 · 1 comment
Open

Support for "capacity" #1

davidberneda opened this issue Jun 15, 2015 · 1 comment

Comments

@davidberneda
Copy link
Owner

When adding many child nodes to a node, better speed could be obtained by using a Capacity private property, to resize the internal children array few times instead of once per each added node.

Pros:
Speed when adding many many nodes

Cons:
The extra "Capacity" field adds 8 (or 16 in x64) bytes per node (more memory used) because an extra "Count" field should also be added, to remember the actual number of child nodes.

@skamradt
Copy link
Contributor

skamradt commented Mar 20, 2024

This is implying that the internal number of children is limited to an nativeint so when compiled for 64bit, it can hold more since the limits of a nativeint are larger. Is it feasible to have that many children? Or can it be limited to a FixedUInt/LongWord and still maintain only 8 bytes per node regardless of target? This is an array of children, is 4,294,967,295 not enough for most cases? I would expect the system performance will suffer greatly with that many children (if even possible on 32bit).

If this does move forward, I would suggest a compiler define to determine the max number of child nodes allowed in the array rather than put a memory tax on every node that is not realistic. This way, if someone truly needs more than the 4 billion children on a node, they can recompile with that option on, but the rest of the users would not have to pay the penalty for compiling as 64bit. You already have the redefine for an integer, you could just wrap this around a compiler define and it would be seamless.

Continuing forward I would also suggest a Grow method which given a value of how many nodes to add to the array, would expand the array to allow for that number of new records. If I know in advance that I'm going to be adding a set number of items, this would further reduce the resizing that might otherwise get triggered every n records.

Deletions are also a problem, mass deleting records would potentially leave large gaps at the end of the array. A Pack option would resize the array back down to just what is really available.

An AutoPack public property could be exposed that when set to true would pack the opposite of Capacity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants