Edit: ignore what I've written in this paragraph -- it's for NES, not SNES.
VBlank on NTSC lasts somewhere between 2273 and 2387 CPU cycles. Reference: viewtopic.php?t=7878 -- this thread may interest you in other ways, such as how to visually display on-screen how much time something is taking through some cute/quirky methodologies (the NES can do this a bit easier, but there are ways on the SNES as well, such as, say, by changing the background colour palette entry to an alternate colour at the start of a routine, then back to what it originally was at the end of the routine. The thread I reference has some other methodologies though)
Anomie's timing doc outlines how long DMA takes per byte, however the cycle counts you see in that doc
are not equivalent to CPU cycles.
nocash's SNES document probably has the answer as well, but may still require bits of math be done.
I can't remember how to do the whole "master cycle" to "CPU cycle" conversion ordeal. Someone else should be able to do the math for that (right now I am too lazy to go read + figure it out). Maybe nocash or someone else can provide that. (I should add: this is a very common question when doing NES or SNESdev -- "how much time is available in VBlank" + "how much time does X/Y/Z" take (esp. DMA), so it should be answered in such a way that is very friendly/easy for the software programmer to understand)
The macro you pasted is "general purpose", so how much time it takes is ultimately going to depend on the
size argument.
Speaking generally: the bottom line is, with classic consoles, you cannot update an *entire screen* worth of data (including CHR, if applicable) in a single frame. I don't know if you're doing that, your post is simply too vague. The SNES is not designed for this (full layout + CHR data is the equivalent of full-motion video playback); it's designed so that you update only what needs to be changed. A lot of games that need large amounts of transfers do so across multiple frames (multiple NMIs), as long as visually it won't impact what you're trying to achieve; for example, if you're trying to update some tile map data for animating trees, maybe do some updates in one NMI, then the next do some more, essentially making the animation rate for the trees ~30fps. You get the idea. In general, you have to track/maintain all of this in software. Welcome to game development. :-)