@evildictaitor: Out of interest, what do you recommend instead of XML in high perf systems : binary serialisation? Json?
It depends what you mean by a high performance system, and what you're storing in the XML.
But basically, if you're using your XML to store stuff like configuration options, I'd say keep the XML but parse the file during the startup of your server (or during a config flush) and keep the pertinent data in memory. That way you avoid doing XML operations during the hot loop of your high-perf server.
If your XML is not so much about configs, but more about data storage, something more like SQL server is probably going to be a good choice. Just remember to parameterize all of your statements and put the parameter strings as constants in the SQL database as stored functions - not only will that protect you from SQL injections, it'll also mean that your queries get precompiled in SQL and that you'll get a massive reduction in the transmission cost between your app and the SQL server, be it an in-proc SQL server, a SQL server on the same machine via a pipe or even one on a different machine.
Also it depends on if your high performance server, is in fact, an IO-bound server rather than a CPU bound one.
For example, if you're using a GPU farm to compute results for a massive simulation like a weather modelling or modelling explosions (a high performance server) then doing XML ops during a hot loop is going to completely destroy your performance. But if you're actually dealing mainly with perhaps 1000 HTTP requests an hour on a webserver, then really you're not a high performance server at all, but just a regular one, and doing a whole ton of XML per page probably isn't going to hurt you.
If you're really asking about whether XML versus JSON is a good output of the server, (e.g. webservices / SOAP / REST server) then the thing to bear in mind is that the cost of doing XML memory operations is nothing compared with the cost of pumping those bytes around the world over the Interwebs. JSON will give you a speed boost not because it has fewer string operations or because it is easier to parse, but simply because it is smaller and will take fewer packets to send it from your server to a browser or vice-versa.