Cut to the chase...
To cut your XML-processing time dramatically, sudo gem install nokogiri then add the following to config/environment.rb inside the Rails initializer.
config.gem "nokogiri" ActiveSupport::XmlMini.backend='Nokogiri'
Back-story and pretty pics
So, our site makes heavy use of ActiveResource , meaning that most of our data is located remotely.
Not surprisingly, some of our pages are *really* slow, so I landed the task of speeding them up. Apart from page-caching (not possible), fragment caching (only helps on the *second* hit), or some complicated messy idea of data-caching locally (tedious and likely to be evil); my first thought was to reduce the number of network hits. Clearly that's a high pain point, especially on our heavy pages that have many resource fetches.
Before I dove into performance hacks and updating the business logic into twisty little data reuse-patterns for network-hit reduction... I decided to actually try profiling.
I'm really glad I did, because when I ran it over our heaviest action, I saw that all the highest-weight method-calls led back to some form of ReXML parsing.
Searching on the ReXML components showed that the heaviest ReXML method took up a whopping 1 million process cycles. When our total process-cycles came to 5.8 million - that's a significant chunk of time spent in that one library.
As I mentioned - our site makes heavy use of ActiveResource, and one *big* problem with ActiveResource is that all your objects are parsed and re-parsed as xml for every fetch of data... so, in hindsight, it's fairly obvious that our site would spend a *lot* of time in the XML-parsing library. Any speedup in that department would help us immensely.
We've recently been to Rails underground, and one of the lectures had a slide comparing the speed of ReXML to several other ruby XML-parsing libraries. Nokogiri came out as a clear winner in the speed department. The loser was equally clear... that being the Rails-default: ReXML
So, switching out the library would be an obvious speed win.
As it turns out - it's really easy to do this. Just install the gem, and require it in your Rails initializer using the instructions at the top of this post
But did it really help?
It seemed faster... but can we prove it?
 through the HyperactiveResource plugin
I'll be giving a talk at LRUG on 12/08/2009 on how to use and interpret ruby-prof and kcachegrind
During the talk by Maik Schmidt on Sneaking Ruby & Rails Into Big Companies
 I'm not sure, but it's possibly the one from this page comparing Ruby-XML performance benchmarks