avm1/core: List of general performance issues and potential improvements

[adrian17]

• do_action, Action handling and parsing

  • Big Action object size
  • Core loop with do_action showing up standalong on profiles - maybe some cheap wins to be had there?
  • Expensive parsing
    • byteorder and propagating io::Result is relatively slow
      • Solution: refactor with cheaper API? But that loses error information if we encounter invalid action.
    • read_push allocating vectors for each push
      • Solution: as above, refactor reader to pass cheaper-to-parse slices

• Expensive property accesses

  • Hashmap accesses are done several times per action (has_own_property() into get_local() etc)
    Same with scope: locals().has_property() into locals().get()

    • Solution: add an Entry-like API to objects?

  • Major overhead related to string hashing

    • Need to do string-insensitive hashing even in AS2 mode
      • Solution: find a way around this?
    • Case-insensitive hashing is expensive due to UTF-8 traversal and bad generated code (swf_char_to_lowercase not inlined while having a fast exit)
      • Solution: different internal string representation? Cheaper case-insensitive hash function?
    • Most accesses are done with a small set of strings
      • Solution: store hash in AvmString and propagate it instead of &str?
        Also: string interning?
        Also: a single pool of static strings with const-calculated hashes?

  • ChildContainer::get_name doing a slow loop over all children

    • child.name() is expensive due to "virtual-like dispatch" and RefCell/Ref usage
      • Solution: make DisplayObject hierarchy more C++-like? (as in, common base object layout)
    • String comparisons don't compare string lengths and do full iterator comparisons
      • Solution: do early check for string lengths? (But that in turn slightly slows down PropertyMap, as there most string comparisons are already likely to be equal)
    • Also: use a hash map for faster accesses? But that's a lot of extra complexity, and linear loop shouldn't be that slow.

• Timeout checks still take up to 10% of time

  • Solution: decrease frequency even more? Just make sure that doesn't break them (might need to move actions_since_timeout_check from Activation to UpdateContext) Reduce frequency of timeout checks by 10+ times #3628

• General function call overhead

• run_stack_frame_for_method doing relatively expensive Activation::from_nothing for each attempted call, even if most objects don't have the handler

  • Solution: search for handler without holding an Activation?

• GC alloc overhead

  • For big objects, MutationContext::allocate memcpys the object on stack several times per allocation
    • Solution: Optimize gc-arena to reduce useless moves. Nightly Rust's Box::new_uninit would have helped too.

• Tessellation

  • Done eagerly for every shape, takes a lot of time in general
  • That includes font shapes - even if 99% of glyphs aren't needed they are lazy now
  • Also: sometimes we tessellate identical shapes

• Memory overhead of shapes

  • All parsed SWF shapes are stored in memory, in case they are needed for hit tests - up to 800MB in same games
    • Solution: Better pack ShapeRecords in memory (2-4x memory savings)
    • Solution: Load shapes lazily if they are needed for hit tests