Pretty cool. Something is wrong in the top left quadrant though, the graph tooltip becomes a little sluggish when it is anchored to the bottom right of the cursor. Might be related to array reversals, etc.
I would be shocked if that was the cause of any lag - D3 selections are essentially nested wrappers around HTML nodes. .node just grabs the first one in a selection.
It seems that in the left-right quadrant it is doing more expensive full-width paints, which explains the lag. It is caused by the small highlight rect, but I couldn't figure out why.
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).
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.