network.http.sendSecureXSiteReferrer;true
    network.http.sendRefererHeader;2
    network.http.referer.trimmingPolicy;0
    network.http.referer.spoofSource;true
    network.http.referer.XOriginPolicy;1

The transforms no longer take as much CPU time as they used to, due to having better SIMD accelerated versions. Much of the time is now spent on the PVQ decoder, which is not optimized for speed at the moment.

One thing I learned after writing large fixed-function transform hardware is that it doesn't take much extra hardware to turn them into microcoded programmable pipelines, much like a GPU. In fact, this approach is very common internal to hardware video decoders, though the firmware is not exposed to the user. One notable exception is Broadcom's Videocore IV, which is quite an interesting architecture [2].

Also, with the latest mobile processors having 8 or more ARM cores, we can also exploit CPU parallelism in much the same way. I feel it is very important to have the codec perform well on CPU alone, as not everyone will have hardware that can decode it right away. This is something I would like to play with a lot more.

[1] http://thomasdaede.com/wordpress/?cat=9 [2] http://www.broadcom.com/docs/support/videocore/VideoCoreIV-A...

[0] http://arewefastyet.com/

[1] https://areweslimyet.com/

[2] http://arewee10syet.com/

Not mozilla though.

Also: https://github.com/ttaubert/arewesmallyet

[0]http://arewedubstepyet.com/