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.

Sign up for GitHub

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

Jump to bottom

Identify DotvvmProperty with systematic 32-bit IDs #1867

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from
Draft

Identify DotvvmProperty with systematic 32-bit IDs #1867

wants to merge 1 commit into from

Commits on Nov 3, 2024

  1. Refactoring of DotvvmProperty value storage 

    All DotvvmProperties are now assigned 32-bit ids, which can be used for more
efficient lookups and identifications. The ID is formatted to allow optimizing
certain common operations and make the assignment consistent even when
we initialize controls on multiple threads.

The ID format is (bit 0 is (id >> 31)&1, bit 31 is id&1)
* bit 0
  - =1 - is property group
    * bits 16-30: Identifies the property declaring type.
    * bits 0-15: Identifies the property in the declaring type.
  - =0 - any other DotvvmProperty
    * bits 16-30: Identifies the property group
    * bits 0-15: Identifies a string - the property group member

All IDs are assigned sequentially, with reserved blocks at the
start for the most important types which we might want to
adress directly in a compile-time constant.

IDs put a limit on the number of properties in a type (64k),
the number of property groups (32k), and the number of property
group members. All property groups share the same name dictionary,
which allows for significant memory savings, but it might
be limiting in obscure cases.

As property groups share the name-ID mapping, we do not to keep
the GroupedDotvvmProperty instances in memory after the compilation
is done. VirtualPropertyGroupDictionary will map strings directly
to the IDs and back.

Shorter unmanaged IDs allows for efficient lookups in unorganized
arrays using SIMD. 8 property IDs fit into a single vector register.
Since, controls with more than 8 properties are not common, we
can eliminate hashing with this "brute force".
We should evaluate whether it makes sense to keep the custom
small table--optimized hashtable. This patch keeps that in place.
The standard Dictionary`2 is also faster when indexed with integer
compared to a reference type.

Number of other places in the framework were adjusted to adress
properties directly using the IDs.
    @exyi
    exyi committed Nov 3, 2024
    Configuration menu
    Copy the full SHA
    4745066 View commit details
    Browse the repository at this point in the history