There is no one answer other than "it depends".
First off, what is the hardware equivalent of polling? It is the clock, logic is generally evaluated every clock cycle, so the interrupt line will be examined by the logic every cycle. That doesnt mean that interrupt signal is generated by the perpheral one one cycle and is evaluated the next cycle. "It depends" on the design, it may be a few or many or dozens of cycles.
As you know being in software, first the processor either has to wait to finish the current instruction, or aborts the current instruction, then you have to fetch the vector table, maybe there is a mmu table you have to read through in order to find that, maybe not. Maybe you had to switch from user to superviser mode along the way, it depends on your code and design. Also you are flushing the pipe, finding the isr, fetching those, filling the pipe. Then software needs to save state, so you are pushing registers and flags to the stack, this could take an eternity, with the layers of memory you may have, or wait states on the speed of the ram, etc.
Then depending on the design of your system, you may have to wander through the peripherals or at least ask the interrupt controller who caused the interrupt. then go to the peripheral and ask it why. Eventually figuring that out and now
You can service the interrupt.
Then you may have to re-arm the interrupt, or clear it at the peripheral and maybe other places in between. Then restore the state of the machine, reading from ram which may or may not be cached or may be in slow memory, may be wandering through an mmu again.
And finally return from the interrupt.
Polling, now polling is not necessarily every some fixed unit of time, it is wherever in the code you choose to poll, you might have every other line of code check, you might have one time through your main loop check, and the time through the main loop may vary depending on what you are doing in that loop and what tangents it can take.
But to compare, or beat interrupt performance, one could craft an example that does nothing but poll in a tight loop, polling the peripheral status directly, if a cache the code is in cache fetching quickly, depending on the design of the core, and what you have enabled you may have branch prediction on and since this is not a conditional loop, it should always predict right and save a few cycles flushing the pipe to go through the loop again. when you do see the status change you branch out of the loop and start servicing it immediately. you may still have the mmu hit, cache and other but you dont need to save the state of the machine, you dont need to talk to an interrupt controller nor ask the peripheral what happened, you already know, you basically branch directly into the
service the event.
and then you can branch back into your main loop.
So it is quite simple to craft an experiment were polling outperforms interrupts by a large margin. As well as where interrupts outperform polling. As mentioned you could have a large main loop, but poll a particular peripheral every other line or something, although wasteful still get good response time. probably better to use an interrupt.
it is all about doing your system engineering, understanding and timing the worst case execution paths. many a realtime system has been made with polling only and no interrupts. likewise many a system has been made that is strictly interrupts.