Hi, currently Bitwise is trying to get all of the Mozilla testsuite to run and pass, not a small job as it hasn't even worked since about FFv4 when Walter did a lot of work on it. The testsuite is what Mozilla expects to pass before releases and even after new commits.
So far, he has fixed a couple of memory related problems including fixes to libc and/or libcx and moved from mmap to native memory allocation in places. There's no way to say if running the testsuite will show our problems but it is a good start.
Currently dmik is trying to implement some type of tracing to see where the code is spending its time. Hopefully that'll help but Mozilla uses lots of JS, XUL and such to draw the browser so who knows.
As for SM being currently faster then FF, it is probably a newer build depending on which FF is used. I was also experimenting with different compiler options, eg optimizing for size rather then speed, which may be why the DLLs were different sizes. Unluckily enough time has gone by that I forget exactly what I did. about:buildconfig will show the compiler flags I (and dmik) used with -Os being for size and -O3 for speed. Probably best is -O3 for the JavaScript engine and -Os for the rest, smaller binaries take less memory.
Here I find that SM performance is great if started in safe-mode and as extensions are enabled, it gets worst, especially some extensions. TB is worse and just mouse overing it can peak both cores for seconds.
A lot of these problems are possibly intrinsic to the design of Mozilla and that is one reason that they're moving to the Quantum rendering engine. Other things are getting worse with all browsers as they split it into multiple processes for various reasons, mostly security.