If you have one of the TextView inspectors open to display a huge body, especially if that body isn't text, then yes, Windows will definitely spin a ton of CPU to attempt to render it as text. For huge bodies, especially those that are binary, you're best either limiting yourself to the HEADER inspector, or the HexView inspector (if you want to see the body).
In terms of memory usage, you should generally see roughly a maximum of 200% overhead during the request read operation, because .NET internally grows its buffers by doubling their size each time the prior allocation was exceeded. However, this is in some respects an accounting trick, because the system's virtual memory manager does work to ensure that these allocations are less of a hit on physical memory than the numbers alone might suggest.
Seeing overhead as large as you've described is a bit of a surprise, with the caveat that it's entirely possible that the garbage collector simply hasn't yet run due to a lack of memory pressure on the system; clicking Help > About forces a GC and can eliminate that as a culprit.
Check out the Telerik Platform - the only platform that combines a rich set of UI tools with powerful cloud services to develop web, hybrid and native mobile apps.