Firefox
Some quick hacks
userContent & userChrome
Make Browser Tab Bar More Compact
about:config
browser.uidensity
: 0 is the default, 1 is compact, 2 is touch (sparser)
Improving Firefox responsiveness on macOS - Mozilla Hacks - the Web developer blog
- This improvement was achieved via a slight change in how locking is implemented within Firefox's memory allocator.
- Putting a thread to sleep has significant performance implications and, thus, is not always the best option.
- it might be advantageous to let a thread spin briefly if the lock it's trying to acquire is only held briefly.
- It can result in higher performance and lower power consumption, as spinning costs less than sleeping.
- As you might have guessed by now,
OSSpinLock
offered excellent performance on a lightly loaded system but behaved poorly as the load ramped up. - This problem with
OSSpinLock
was known within Apple hence its deprecation - Enter
osunfairlock
, Apple's official replacement forOSSpinLock
. If you still useOSSpinLock
, you'll get explicit warnings to use it instead - So I used it, but the results were terrible. Performance in some of our automated tests degraded by as much as 30%.
- As it turns out,
osunfairlock
doesn't spin on contention; it makes the calling thread sleep right away when it finds a contended lock - The function is
osunfairlockwithoptions()
and the options I used areOSUNFAIRLOCKDATASYNCHRONIZATION
andOSUNFAIRLOCKADAPTIVESPIN
- The latter asks the kernel to use kernel-space adaptive spinning, and the former prevents it from spawning additional threads in the thread pools used by Apple's libraries
- Did they work? Yes! Performance on lightly loaded systems was about the same as
OSSpinLock
, but on loaded ones, they provided massively better responsiveness - I initially fell back to
OSSpinLock
as an intermediate solution on older systems. Later I managed to get rid of it for good by relying onosunfairlock
plus manual spinning in user space