I’d heard other people in the community mention that, while ColdFusion 8 was faster, object creation was notoriously slow. I never understood what they were talking about as I was creating up to 3000 DTO objects to pass to Flex and was seeing times between 300ms-2000ms for the entire process.
Well, today I discovered what they were talking about. While architecting a new piece of functionality in one of our apps, I needed to create a DTO that has 57 properties. Also, the data set for each user averages 1000+ rows (and, thus, 1000+ DTOs created). The execution times startled me at first.
Here are my notes.
With 57 Attributes
==============================================
300 rows
==============================================
4438ms for converting to DTOs (100% slower)
2216ms for no conversion
1070 rows
==============================================
10485ms for converting to DTOs (198% slower)
3516ms for no conversion
With 20 attributes
==============================================
300 rows
==============================================
2250ms for converting to DTOs (20% slower)
1875ms for no conversion
1070 rows
==============================================
5735ms for converting to DTOs (144% slower)
2344ms for no conversion
I always knew that the number of objects created would always increase time, but I never realized that the size of the object would have such an impact. In the past, I’ve always dealt with DTOs that had less than 10 properties.
Now we have to make a hard decision on when, or perhaps how, to implement DTOs when using ColdFusion to send data to our Flex UIs. We either have to come up with a way to do pagination in our requests (only request 200 rows at a time for large objects), or abandon DTOs altogether and work with the native ArrayCollection type passed back for ColdFusion queries. I’d hate to lose my types data objects in Flex, but if the impact is making a user wait for 10 or 20 seconds for his/her data to load, we’ll have to find an alternative.
12 Responses for "ColdFusion Object Creation Performance Hit"
When dealing with these large data sets, are you returning an array of CFCs to Flex?
What I settled on in some cases was sending back structures with the “__TYPE__” key specified so that Flex sees them as the necessary VO. The problem comes in when dealing with complex composed objects. You aren’t going to convert every composed element to another typed structure as this could get complex, so for populating grids I have passed a “lightweight” version of the VO without all the properties filled and request the full (as in fully composed) VO when working with a specific item.
You can use CF8s built-in LiveCycle to handle pagination.
http://www.adobe.com/devnet/livecycle/designer_scripting_samples.html
If I remember right, there’s pagination for Flex built into CF7+ Remoting, but I haven’t used it in quite some time.
@Brian,
That’s where I was going with my question, the “__type__” value object struct is a huge help when returning multiple objects to Flex. As far as composition goes, I’m playing around with a recursive method for dealing with queries, I do have it working for returning a single CFC with other CFC properties.. and I’m very happy with the speed so far.
Cheers..
@phil: yes, I’m creating CFC arrays and sending to Flex – which has matching VOs so that I can have typed objects.
David, the build in LiveCycle license is only good for 1 CPU, which pretty much removes it as an option.
To me, the issue of CFC creation overhead is rapidly becoming THE issue facing ColdFusion. If CF9 doesn’t deal with this (and by deal, I mean improve the object creation time at least tenfold), then the additional features like Hibernate integration and Flex integration are going to be virtually meaningless except on very small projects. With options like Groovy rapidly gaining traction, this could really impact negatively on CF. Let’s hope they can pull it off!
First of all your correct that loading of objects (classes) is slower in CF8. Well not technically CF8 but with the Sun JVM 1.6.0_4. There is a known class loader bug that is the cause of this. This is NOT Adobe’s problem it is (or was) Sun’s problem that has been fixed as of the 1.6.0_10 version. I’d be interested in knowing which JVM version your running. If your running the old version try upgrading and run your tests again to see if the problem is reduced or even resolved.
I wrote a blog post ob the JVM versions and which ones you may wish to be using. Here is the link from that post to Sun’s bug report which reports the bug is fixed.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6566201
@WilGeno: I’m actually using update 10. However, you’re right that update 10 is faster than update 4 because when I upgraded, I did see a measurable performance gain.
[...] up on my original post about ColdFusion performance hits on creating objects – it was suggested that I return an array of typed structures instead of an array of [...]
why is that if someone else in the community saids that the object performance in CF needs to be addressed, everyone agrees with them. Yet I’ve been making this arguments since cf8 came out and i’m considered a jerk off?
@dfguy: I haven’t the slightest clue. Are you certain that you are considered a jerk off? How did you come to that conclusion?
Hi,
We used iterator pattern to fix this issue, but we used this iterator at cfm pages, I don’t know about Flex.
So inside iterator we converted queries to struct and then during iteration we mapped the values to one cached object.
So it helps us to keep the patterns and also be fast.
Leave a reply