tooltip.node()
Can't imagine that being the bottle neck, but it seems to be the only non-symmetrical code path. Might try and profile and see if anything pops up.
https://github.com/mbostock/d3/blob/master/src/selection/nod...
Not sure what else it could be though, unable to duplicate.
The tooltip movement becomes laggy as soon as I move into the top left quadrant. No noticeable difference between any of the other three quadrants.
The cost is indeed in the paint (the lagging top-left quadrant redraws the whole map svg).
The difference in the tl and other quadrants is that the other quadrants were causing a synchronous layout because they were asking for the highlight's size to position the tooltip. And this was _faster_, because the different sequencing of layout and paint resulted in a less expensive (partial) paint.
BTW, if you actually want to make this kind of tooltips for complex SVG I recommend having the continuously updated part to be in its own HTML element with styling to make it hardware-accelerated ('div style="-webkit-transform: translate3d(...)'). That way only the changed parts are repainted and the compositing is done by the GPU.
(Well, actually modern IEs are very good at optimizing the SVG changes, but Webkit isn't).