The savings I'm referring to are space savings and reduction in GC frequency. The one-time cost of allocating accessors in a prototype somewhere, and having some consts in global variables, is going to be insignificant by comparison to the accumulated per-object space wins.

But maybe you're talking about speed. After warm-up, accessors and consts carry no cost. Before warm-up, it's probably still a net win to have bitfields.

After warm-up, in WebKit at least, accessors will get inlined and the compiler will be smart enough to constant-fold references to global variables (or almost any other kind of variables) that were effectively constant.

As for before warm-up, it depends on how frequently the object in question is allocated. Accessing through an accessor before warm-up carries some cost, but on the other hand, allocating 4x fewer bytes could be more important. It depends on the application. If your app uses too much memory to run reliably on some devices, then you'll probably be fine with losing some perf before warm-up in exchange for being able to not run out of memory. Also, GC is expensive and it is triggered by the combination of how much you allocate (in bytes) and how much is live at any time (in bytes). So reducing the sizes of objects reduces the amount of GCing you do, which causes your program to run faster. Probably in lots of large apps, the speed-up from GCing less will be greater than the slow-down from accessor calls during warm-up.