WireBox performance issues with object creation

Hi Jose, The performance issues I outlined a while back were largely due to repeated calls to getMetaData(). ColdBox 3 Final began caching that will helped dramatically. Also, when I moved from CF8 to CF9, it got even faster.

I guess lets start out by figuring out what version of ColdBox/WireBox you are on. (See our subject line conventions)

Also, in your example, is the “createOBject” and “new userBean” versions creating all the composite objects as well, or just the user object? Also, are you calling the init() methods after creation? If not, that’s not a fair comparison. Either way, how many times are you running those creates? Surely it isn’t taking 48 seconds for a single creation.

Also, what types of dependencies are you injecting? Are those singletons which are only created once, or are they transients. In my original post, all the dependencies were singletons so they were only created once, and then all other creations were just injected with a reference. I never inject transient beans directly. One reason is I like to wait to lazy load them when I actually need them, and secondly, that gives me more control over how they are created. I prefer to get all beans from an applicable service. Therefore, if a user has an address, I inject the addressService into my user, and when the user needs to lazy load an address, it asks the addressService to fetch it which allows me to encapsulate the logic of how to create and retrieve a user’s address. It would be much more difficult to autowire in a call to a service. (Which you CAN do, because WireBox is just that amazing but you can’t specify parameters.)

And lastly, while running your test, switch over to a tool like SeeFusion and pull some stack traces at random intervals and look for any code that continually is being executed to try and find the slow points. It could turn out to be code in your own init() method.



Hello Brad,

Many thanks for the quick and detailed reply. I saw the rules on subject line conventions after I posted. Sorry about that! I now know the proper convention going forward.

I’m using WireBox 1.5.0 standalone. The app uses MVC conventions, but no MVC framework. We had considered migrating to ColdBox entirely, but decided against it due to our January deadline.

The “CreateObject” and “new Bean” tests instantiated composite objects all the way down the chain via the init method. I verified this by running these CFDumps on the first index of the users array.

arrayAppend(users, createobject("model.OldUserBean").init());

For my WireBox test I ran the following:

arrayAppend(users, application.wirebox.getinstance("userbean"));

All the beans are no scope/transient objects. The application does use a number of singletons, but the beans have to be transient. In the non-WireBox test, the only thing the init methods do is call CreateObject.

It sounds like our tests were quite different. Your test instantiated singleton dependencies into a transient whereas mine instantiated transient dependencies into a transient. Perhaps the transience of all my connected beans is causing the huge performance disparity.

I really like your idea of handling the lazy loading via a Service. From what I’ve read in the docs, it’s okay to have a singleton injected into a transient. The other way around is to be avoided since it would introduce scope widening. Is that correct? I will look into going this route and let you know what I find here.

SeeFusion is also a good recommendation. Up until I’ve only looked at the ColdFusion debug output.

You guys rock. Thanks again!


Yes it is very ok to store a singleton into a transient, in fact it should be more widely understood on how it works. Not saying you don’t but a lot of people don’t understand this behavior at all.