I am currently working on a standalone (Adobe)Flash chat Client that, similar to Michael Washington's IWeb Module, talks to a DNN hosted aspx-page (the Gateway), that again returns the data as a well formed XML document.

Here, when it comes to performance, I am not happy of being forced to run through all the ASP.NET pipeline that triggers many things I do not need and therefore will unnecessarily throttle overall DNN performance.
So the question here is, whether there is a way to control the pipeline, or at least, whether there is an option to bypass certain HTTP Module handlers for some exceptional requests. Best would be to have a way for telling a single aspx page which HTTP Modules (and only those) to execute.

What worries me even more than just the performance issue, is, that anybody, anytime might add HTTP Modules to the pipeline that might have an even worse impact on my Gateway's function, respectively the well defined XML-Response it generates ( in my case - the response always needs to comply with a client side *.xsd definition file).

Currently I see the following options to deal with this:

1. Defensive
I am not sure whether the Core Team should be aware, that with an upcoming need for web-services, AJAX-requests and other types of "callbacks", adding more and more functionality (and "if" statements) to the pipeline might significantly impact overall performance. Here I suggest to eiterh put "global functions" somewhere else (something that can be dynamically switched on or off), or to provide a hook to unregister or bypass HttpModule Handling for specific Requests.

2. Radical
Ignore DNN completly and get the data from the native Database. Although this migth be the most performant solution, it is disastrous from an administrative and security point of view (e.g. managing security at two places).

3. LowLevel
Bypass IIS and call the dlls directly (RPC). Might be a good solution for some individually customized installations, but not very useful in a world that increasingly builds on the web.

4. Dedicated Gateway Marker
It might be a good idea to specify a path- or file-name or some other type of marker for the identification of facade items (such as an aspx page) that will be ignored by all standard DNN HttpModules.
So what I have in mind in some kind of "if  (URL == Marker) then exit" clause to be used in every HttP Handler's init() function.

Any other ideas ?

yes, writing my own Http Handler might be an option that falls in the Nr. 4 categorie of alternatives, as the *.ashx extension provides a "hook", that might easily be used in the DNN Http Modules to treat Http Handlers differently.
However this does not solve the pipeline issue, as the current  DNN Version 4.5.1 standard Http Modules (e.g. UrlRewrite-, Personalization-  and DNNMembershipModule) are still fired when calling an *.ashx file as well.
Further we might face some challenges when installing our own Http Handler as this

a) requires the web.config to be changed (some risks for the non experience users, and eventually even a no-go for large environments, where the DNN application must not be restarted).

b) would require all DNN Hosters to allow HTTP Handlers (*.ashx) to pass IIS (which some might not do as some older DNN versions did not need *.ashx files in the past).  

Concerning performance writing my own HttpHandler might be in general a faster option than writing an ASPX-page or a WebService (*.asmx) - here you are right - but concerning the pipeline issue it's all the same, I guess.

I looked into this myself about 6 months ago, and came up with the same conclusion, because you're not using an aspx page, when it comes down to it there is actually very little performance cost.

Chances are if you do take the time to remove a bunch of processing you're going to wish you didn't...  are you going to want to have your chat application have access to the user roles that the logged in user has access to?

Any chat application happening over HTTP is going to be a big resource expense - not only at the server end, but at the client end because of the constant poling.

There is a WHOLE lot taking place that you don't even see for each web request already...  making binary decisions and creating small objects in memory isn't nearly as resource intensive as doing things like polling a database - network traffic and disk access are the major culprits of performance on web applications.  Overall, the memory footprint on DotNetNuke isn't that bad.