Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Feedback ComponentDataFromEntity improvement

Discussion in 'Entity Component System' started by felipin, Mar 27, 2019.

  1. felipin

    felipin

    Joined:
    Nov 18, 2015
    Posts:
    49
    What about a method like this in the next version:

    upload_2019-3-27_19-24-8.png

    I think it'll be a 2x faster way to read and write a component data with ComponentDataFromEntity
     
    Last edited: Mar 27, 2019
    JesOb, NoDumbQuestion and Guerro323 like this.
  2. NoDumbQuestion

    NoDumbQuestion

    Joined:
    Nov 10, 2017
    Posts:
    186
    Note that you have to add
    unsafe
    to function implement this or otherwise it won't compile.
    To use
    ref
    you should pass it to function not
    var something = ref value


    Maybe instead of return ref, return pointer to DataComponent instead. We can figure out how to get value from pointer
     
    felipin likes this.
  3. felipin

    felipin

    Joined:
    Nov 18, 2015
    Posts:
    49
    NoDumbQuestion likes this.
  4. NoDumbQuestion

    NoDumbQuestion

    Joined:
    Nov 10, 2017
    Posts:
    186
  5. julian-moschuering

    julian-moschuering

    Joined:
    Apr 15, 2014
    Posts:
    529
    Issues I see:
    * If the ComponentDataEntity is marked ReadOnly you may not return a ref value. Could be fixed by either throwing or using a temporary copy that is ref returned.
    * It's not possible to catch accesses on the returned ref when the memory is invalidated or used for something else eg due to a structural change. This might result in random errors and access violations.

    The speedup is probably not existing most of the time (in standalone + burst) as most components are small enough to be stored in registers which will basically result in the same code with or without ref return.
     
    felipin likes this.
  6. felipin

    felipin

    Joined:
    Nov 18, 2015
    Posts:
    49
    Inside ComponentDataFromEntity there's no field that provides us a way to know if it's a ReadOnly or not, maybe it could be added, so it'll possible to assert this condition :/

    The improvement will be avoiding to search for ComponentType.TypeIndex index inside Archetype.Types (ChunkDataUtiltiy.GetIndexInTypeArray) and some others operation to reach the entity chunk, but the most important is the search in Types array.
     
  7. JooleanLogic

    JooleanLogic

    Joined:
    Mar 1, 2018
    Posts:
    447
    TypeIndex is cached. I don't think there's much cost involved there.

    As Julian said, I'm not sure of the overall perf benefits but ref return would be nice syntactically to not have to write back to the ComponentDataFromEntity.
    Perhaps it would be possible if there were RO and RW versions of ComponentDataFromEntity?
    Code (CSharp):
    1. struct ComponenDataFromEntityRO<T> ... {
    2.     public ref readonly T this[Entity entity] {...}
    3. }
    4. ref readonly var comp = ref CDFERO[entity];
    5.  
    6. struct ComponenDataFromEntityRW<T> ... {
    7.     public ref T this[Entity entity] {...}
    8. }
    9. ref var comp = ref CDFERW[entity];
     
    Last edited: Mar 28, 2019
    M_R, JesOb and felipin like this.
  8. julian-moschuering

    julian-moschuering

    Joined:
    Apr 15, 2014
    Posts:
    529
    Thats what the AtomicSafetyHandle is for: CheckWriteAndThrow/CheckReadAndThrow.

    You are right, there might be a little bit to be gained there.

    Probably just add two functions: GetComponentDataReadOnly, returning the value and doing a CheckReadAndThrow and GetComponentData, returning a ref value and doing a CheckWriteAndThrow.

    Still as long as memory corruption can't be prevented this will most likely not get added.
     
    felipin likes this.
  9. felipin

    felipin

    Joined:
    Nov 18, 2015
    Posts:
    49
    I think this is the best approach