Swf benchmarking

[madsmtm]

I've never done performance optimizing and such before, but thought I'd try help out. Spent the day making benchmarks for the swf module, but only wayy too late did I realize that it's actually not really a bottleneck in comparison with other parts. So I'm putting this here for posterity, but I'll close the PR myself since it's not actually useful 🙄.

Some short profiling on a flash game found that a lot of time is spent in TObject::get for ScriptObject (which makes sense if there's a loop somewhere accessing a lot of attributes). Might be worth looking into optimizing/memoizing property_map::swf_hash_string_ignore_case and perhaps researching different hashing methods for PropertyMap.

[adrian17]

Are you on discord? I investigated this a bit too :)

but only wayy too late did I realize that it's actually not really a bottleneck in comparison with other parts

Actually, sometimes it's definitely a nontrivial factor. For example, in Meat Boy (IIRC) and some other game, in main interpreter loop:

and

And loading shapes in Infiltrating the Airship:

Most of the overhead in reading comes from byteorder and bitstream-io reading bytes from array with Read::read_exact, which is a relatively heavy abstraction (I even filed a bug for it in Rust: rust-lang/rust#80277 , there's also rust-lang/rust#47321), especially on wasm; and from propagating the io::Result around, which also is quite heavy compared to Options.
I would expect that a byteorder-like library that only supports &[u8] (so it's not limited to Read API) and returns Options would be much faster here.

Might be worth looking into optimizing/memoizing property_map::swf_hash_string_ignore_case and perhaps researching different hashing methods for PropertyMap

#848 and #2800 were the early steps to possibly storing hashes inside AvmStrings, so you could avoid rehashing constants like most property/variable names. That's a heavy refactoring though, so it wasn't a priority yet.

[Herschel]

I've been keeping an eye on this crate (https://github.com/nickbabcock/bitter) for dedicated [u8] slice bit-io. It added big endian bitstream support over the past week, so possible we could switch to it now. It'd also be easy to switch over our Readers to not use byteorder and operate directly on the slice as well (assuming u32::from_le_bytes generates nice code) for general aligned reading.

It's useful to have these criterion benchmarks in the repo in general (#787), so I welcome additions like this :-)