Gas cost difference between storing/accessing addresses natively compared to converting them to bytes32 or uin256

I've been working on an ERC20 token which requires me to check if a unique hash combination between an address and a timestamp exists, the timestamp is of type uint256. Would it be more efficient to convert the address to uint256 and concat the timestamp using addition then generating the hash using keccak256, or store them in separate arrays? I'm open to any and all suggestions as a novice to smart contract optimizations.

What do you mean using separate arrays?

Using addition to generate your hash preimage does not sound good to me, it's not an injective encoding.

By separate arrays I meant to have to have the addresses stored in an address and the timestamps be stored in a uint256 and generate the hash for the both of them added together and stored in a bytes when the lookup function is called. My original idea was to concat them together to generate a hash that will be stored in a bytes before the look up is called. I'm under the presumption that since the address and timestamp cannot both be identical at the same time, so the resulting hash from adding both will be unique. Is there something I'm not understanding about how this process works? Thank you for any assistance.