Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We have recently replaced binary based communication protocol with XML one (between browser based client and server). The implementation is almost complete, however I am looking for ways to improve its performance both for faster transmission and parsing. Any ideas ? Please post link along with the answer.

share|improve this question
Am I the only person who just lost all faith in humanity? – aaaaaaaaaaaa Dec 18 '10 at 19:41
up vote 2 down vote accepted

I presume this is a web service and using C++ as a mod extenstions to a web server rather than writing your own.

To speed up transfer you could be able to enable gzip compression on the web server, this is relatively straight forward in all modern web servers.

Parsing could be sped up by:

  1. Reducing node count - can the data being set be reduced, can some be inferred from others?
  2. If you are using a DTD/XSD, have a local copy and resolve to this rather than necessarily always pulling it from the public location. I have seen an XML library pull it from the public location each time which slowed down parsing considerably.
share|improve this answer
Note that the lowest gzip level gives good performance with relatively few cpu cycles. The higher levels do - in my experience - not pay off. – user1249 Dec 18 '10 at 17:42

Use compression if you have the needed computing power on both ends.

share|improve this answer
Any links ? – Gaurav Dec 18 '10 at 13:44
  1. Were I you, I'd avoid premature optimization, and just make sure The Damn Thing Works when deployed to your users. You can optimize later if it's an issue.
  2. Binary for text is an engineering tradeoff. You gave up performance to get portability and human-readableness. Equivalent Exchange and all that. You could just accept the engineering tradeoff and move on to other things.
  3. Keep the binary fat-client implementation around to satisfy the few people who do complain about performance. And when they complain, tell 'em to use the client.
  4. As a last resort, kill all whitespace between tags and shorten tag names. Use default namespaces to avoid extraneous prefixes.
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.