Can you tell us a bit more about the situation? Even at the "slow" 22k/sec number it seems unlikely an app could be bottlenecked on this.

The app has a list of DOM elements and as the mouse moves, it checks if the current mouse position intersections any of the DOM elements. If the mouse intersections one of the DOM elements (which could be anywhere in the DOM hierarchy and is why mouseenter/mouseleave events can't be used), an effect is applied to the DOM element that intersects. In jQuery 1.7, the effect was seamlessly added and removed as the mouse moves. In jQuery 1.8, there is a delay in the effect being applied.

This may be a combination of both the decreased performance in outerWidth/outerHeight and offset. Also, the visual delay appears to be limited to Firefox (15 & 16).

I'll try to make a jsFiddle to reproduce this and post it soon.

We know why this is happening, it's related to the accuracy improvements we landed for 1.8. We're not going to revert here, and the only way we can improve the performance here is by implementing #11938 which is a candidate for 1.9.

For this reason, I'm going to close this bug as wontfix. Please follow #11938 if you're interested in seeing this fixed.

It´s even more slow at 1.9 and 1.10

http://jsperf.com/outer-height-in-1-7-vs-1-8/4

I found this bug through source file with two hours debugging and reading source.

I write function using computedStyle to get the width and heigth, this fast the function.

the function need to be the method of jQuery.fn,so you can use it like use other function with jQuery.