• fsamuel's avatar
    cc mojo: Use ArrayDataViews in RenderPasses · edd40fdc
    fsamuel authored
    This CL makes use of the newly introduced Array DataViews
    in cc StructTraits in order to improve serialization (and
    to a lesser degree deserialization) performance.
    
    This CL improves serialization performance by an average of
    18% on an HP Z620. Deserialization performance improves
    between 7 to 10%.
    
    Prior to the ability to inspect Array and Struct DataViews
    in parent StructTraits, we had to do extra work at
    serialization time in order to capture state that spans
    individual structs within a larger struct.
    
    This CL addresses two of those cases:
    
    1. Previously, QuadList maintained an extra array of
    materials. This array existed so that we could preallocate
    the appropriately typed DrawQuads during deserialization.
    StructTraits assume a preallocated type and populated
    fields in that type.
    
    Alternatively we could have deserialized DrawQuads into
    unique_ptrs, but cc required that we allocate DrawQuads
    inline within a buffer in order to minimize the cost of
    allocations (there can be hundreds of DrawQuads in a
    CompositorFrame).
    
    2. Previously, SharedQuadStates were serialized
    independently of DrawQuads. However, in in-memory form,
    DrawQuads refer to SharedQuadStates via raw pointers. In
    order to allow DrawQuads and SharedQuadStates to deserialize
    independently, as was required previously by StructTraits, a third
    array was serialized "shared_quad_state_references" which was equal in
    size to the QuadList. Each slot corresponded to an index in
    the SharedQuadStateList. After the QuadList and SharedQuadStateList were
    serialized,  shared_quad_state_references updated the raw
    pointers in the DrawQuads in the quad list to refer to the
    SharedQuadStates. This required revisiting all deserialized
    DrawQuads again.
    
    In both 1. and 2. additional state needed to be allocated on the heap
    during serialization. In pprof profiling, it became apparent that much
    of the cost of serialization was in SetupContext. This CL eliminates
    that cost.
    
    Performance measures are available here:
    https://docs.google.com/a/google.com/spreadsheets/d/13Y0I-BVDrQC4RHIzMSs0vl0QPe8xFAhYMUAXaxoEqgg/pubhtml
    
    BUG=624459
    TBR=danakj@chromium.org
    CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
    
    Review-Url: https://codereview.chromium.org/2174843003
    Cr-Commit-Position: refs/heads/master@{#408809}
    edd40fdc
traits_test_service.mojom 1.84 KB