Initializing Typhoon factory faster with large number of beans

Question

I've actually around 150 components in my 4 Typhoon assemblies. I initialize the TyphoonComponentFactory with these assemblies on my app launch, and it could be long depending on the number of components and the tagrget iDevice.

For example, the component factory initialization takes around 1200ms on a iPhone4 and 600ms on a iPhone 5S.

Is there a way to speed up the component factory initialization ?

Answer 1

The 'Assembly' style of instantiating Typhoon is designed for the following:

• Incur the main performance hit at initialization time, and be as fast as possible at runtime.
• Provide as much convenience and ease of use as possible.

Its been a while since profiling, but I would guess the two features with the biggest performance penalty are:

Auto-wiring:

There is a new auto-wiring feature that will be released as part of Typhoon 3.0. While still private it is on the main branch and exists in some Typhoon 2.3.x versions. It adds a 25% overhead. Yesterday a feature was pushed to allow turning off auto-wiring.

Collection Scanning:

Typhoon has the following behavior for collections (NSArrays, Sets, etc):

• Any references to other components will result in the built component being injected.
• Otherwise plain Objects, configurations and scalar values are injected as is. . while this feature has the potential to cause a performance impact, in a typical assembly, there are not so many collections that it has any noticeable effect.

This allows for a simple and intuitive DSL, but requires scanning each collection value, which adds overhead. Do you have many collections in your assembly?

Typhoon 3.0:

We'll be doing some profiling as part of the Typhoon 3.0 release. In the meantime, if you have any performance perhaps raise a Github issue and we'll try to address them.

Most minimal Typhoon (not recommended for normal cases):

As a final point on performance: Besides the assembly style of using Typhoon, if startup performance was of particular concern you could use Typhoon in a bare/minimal state by using the TyphoonComponentFactory directly, however this is much more verbose and doesn't have the built-in IDE refactoring, code-completion, ability to resolve components using the assembly interface (with our without runtime args), etc.