To my knowledge, doing that is actually slightly slower in most cases. This is because if you're storing it as an integer one operation must be done to retrieve it: get value from location in memory; and to store it: store value to location in memory. On the other hand, with indiviual bits there are more operations; to get a bit value: get 32 (or whatever) bit value from memory, and then use AND to check the bit's value; and to store: get value from memory, use OR or AND or XOR to set or toggle the bit in question, and then store the value in memory.

But it's probably unlikely that the speed difference will matter in most cases. I'd expect that usually the speed tradeoff is well worth the space advantage

(update:) Thinking about this more makes me think it more of a toss-up. You probably would have a speed improvement if you would otherwise have to get lots of values from memory, because that is relatively "slow". If you're just doing something like going through a bunch of these numbers to check for one or two bits, or to set one or two bits, the way of using lots of numbers will probably be faster, I think. But if you're just using one number for a bunch for a bunch of things you're using a runtime, I'd guess that it would be faster because you could actually keep the value in one register, or it would be easier to cache it. (With perl, we probably don't have any hope of it staying in a register, so the cache is your only hope; and the cache might just as easily cache 32 32-bit values, too.) (All this is of course IMO, and subject to being totally wrong.)