Thanks for the kind words. Really not doing that much, but thank you.
The easiest way to answer this question is to use Extended Events. The specific event you'd be looking for in this case is sql_batch_completed. This assumes one query, in a batch. If you have multiple queries in the batch, you need to look at sql_statement_completed. Either way, these events show exactly the number of logical pages processed by the query. That's your number for memory, accumulated 8k pages. I already gave you a link to the introduction to Extended Events. For more, look at my blog or youtube channel. I've posted a lot of hints & tricks & stuff.
Another way to do this, easier, but actually more costly in terms of the effects on your system, is to turn STATISTICS IO on. This will show every object accessed and the logical pages processed. That will tell you the amount of memory used. I used to primarily use STATISTICS IO, but after finding several instances where it affected all my other measurements, I only use it in targeted circumstances. It's easy and quick, but also a little painful for the systems involved. You'll find that majority of people do just use this because it is so simple while setting up and accessing the information from Extended Events is more involved. In addition to simplicity, the one HUGE advantage that STATS IO has over ExEvents is that it breaks down the IO by object. There are ways to also capture that in ExEvents, but it's quite involved, and frankly, a pain the bottom. I'd only do that if forced to by circumstances (excessive load on the system, the need to automate capture rather than do manual capture, stuff like that).