Performance Improvements for Transfer

Last week we had Robin Hilliard of Rocketboots into the office to help us get the biggest bang for our buck performance wise with the Transfer / MachII / ColdSpring application, and I have to say it was a great session all around.

Apart from imparting upon us a great many ideas for aspects of our
application we could cache, and various other pearls of wisdom, we
turned on Report Execution Times, and managed to find several key
places in Transfer that were sometimes called over 500 times in one
request (we do a fair amount of data movement per request).

For one thing, in all honesty, I had completely forgotten about Report
Execution Times.  I had turned it off when it was making my CFC heavy
applications go into a slow paced crawl, and had quite literally left
it for dust.

However, after turning it on, and just running it over just a few
requests, the key areas of Transfer that would provide significant
performance increases became very apparent very quickly.

This is where all those small, finicky, performance 'tricks' come to the fore very quick –

  • using else/if statements rather than case statements
  • replacing the use of iterators with for() loops that use a counting numeric index
  • playing with different Java Collections for different operations – i.e. ArrayList vs LinkedList
  • Assigning method results to variables before large looping operations, rather than evaluating them every time.
  • ..and other such things

It should be worth noting, that by doing some of these things, the code
ended up looking rather ugly, but with testing, performs faster than
before.  So this is not to say that I went through the entire Transfer
codebase and switched out everything I could find to being the most
efficient I could possibly, in fact that couldn't be further from the
truth.  There are many places in Transfer that use case statements,
even knowing that else/if statements are faster – simply because I find
case statements are more readable, and they are not in places of the
system that are called in numerous succession.  By the same token, I
make extensive use of Java iterators to loop over my collections in
Transfer, as they provide a high degree of abstraction away from what
sort of Collection is being used behind the scenes, but those places
are now limited.  However, by specifically pin pointing aspects of the
system that are critical to the performance of the framework, the
necessary tweaks to the framework could be discovered and acted upon.

So say thanks for Robin for the new performance improvements for Transfer that can now be found in SVN.

Leave a Comment


  • Katsuyuki Sakai | July 1, 2007

    Could you please tell me how to check out from SVN?
    Thank you.

  • Katsuyuki Sakai | July 2, 2007

    OK. I found the way.
    $ svn co

    I’ll try new Transfer now.

  • DanielD | July 2, 2007

    Do you see the same speed increase between the 2 version when you run the code against CF8?

  • Mark | July 2, 2007

    @Daniel: The speed increase should be relatively similar between the two versions. Why do you ask?

  • Robin Hilliard | July 2, 2007

    Hi Mark,

    Yes, it’s often surprising what turns up when you look at execution counts – they’re a great pointer to working out what code really needs to be optimised (limiting the ugliness as much as possible) and leaving the rest in it’s full architectural splendour. As that Knuth fella says: "Early optimisation is the root of all evil".


  • ziggy | July 3, 2007

    Off topic, but is there any hope of your making Transfer work on Bluedragon 7?

  • Mark | July 4, 2007

    @ziggy: it’s on the roadmap, but don’t be expecting it in a short time frame…

  • CraigW | July 6, 2007

    Mark, absolutely excellent work, your ORM library is insanely powerful. Hats off to you, sir!