Code generation instead of reflection

Manfred Karrer's Avatar

Manfred Karrer

27 Apr, 2012 11:46 PM

I like dependency injection but I don't like to use reflection, as it is pretty slow in Flash (also in other platforms). For large applications with 100s of objects injected that really creates some considerably overhead. My experience with a DI framework comes from Actionscript Spring not with RL. We used it in a large application (200k lines of code) and after removing it and doing the DI by hand we improved the start up time from 8 sec. to 5 sec. So that's why I don't like reflection. Doing it by hand is of course a bit boring and generates a lot of boiler plate code. To get around this I have made a proof of concept for a DI framework with code generation ( It is not bulletproof yet and not production ready, but shows the basic Idea.

  1. 1 Posted by Stray on 30 Apr, 2012 11:04 AM

    Stray's Avatar

    Hi Manfred - interesting stuff!

    Swiftsuspenders does its reflection mostly on a just-in-time basis, and the new DescribeTypeJSON Adobe provided (undocumented, but it's there) is also faster. So lots of the old overhead associated with reflection is no longer a big deal.

    Code generation is something we'd looked at - well, we've talked about a mode where you can dump the swiftsuspenders cache as an object that you just new up and feed it for your release build. Having said that, Till is pretty clear that the reflection is so efficient now that it would actually be unnecessary for most use cases.

    I agree that metadata is brittle, and it requires you to alter your class to have knowledge that should be outside of its domain - that's why in Robotlegs we support constructor injection which is metadata-free (though it has limitations around optional parameters). Having said that, I still use property injection myself, because it's so much more TDD-friendly.

    Till has been on holiday, but I'm sure he'll be interested to look at what you're doing when he's back in the loop.

    Thanks for sharing!


  2. Support Staff 2 Posted by Till Schneidere... on 05 Jul, 2012 12:30 PM

    Till Schneidereit's Avatar

    Hi Manfred,

    thanks for your suggestion - and for the great blog post you linked
    to. And sorry for the late reply, I kind of lost control of my inbox
    for a while.

    Much of what follows is an expanded rehashing of what Stray already
    wrote, so sorry for the repetition.

    In Swiftsuspenders, I have spent considerable efforts on getting
    reflection to be as fast as possible and on caching the results in a
    sensible way. While I agree that having to use reflection in the first
    place is a drag, I don't think it's that bad in practice with an
    optimized implementation using DescribeTypeJSON where possible.

    I do, on the other hand, think that having to use an additional build
    step adds friction for a payoff that's simply not worth it for the
    vast majority of projects. I readily admit that not only is this, to
    some degree, a matter of taste, it also is the wrong tradeoff for some
    projects. Luckily, Swiftsuspenders allows you to provide type
    descriptions explicitly, making the injector forego any reflection of
    the affected types. This could easily be used to implement a
    build-time step atop of Swiftsuspenders. (In general, I decided to
    leave type description mechanisms out of Swiftsuspenders except for
    those that are already there and sort of provide a base line.)

    On another note, I don't agree with your characterization of [Inject]
    tags as binding classes to the DI framework. First of all, [Inject]
    works basically the same across all AS3 DI frameworks, so you can use
    it without tying your code to one of them. Second, there's nothing
    forcing any code to use the [Inject] tags at all. They're merely a
    hint indicating "I except this field to be set from the outside"
    without saying by which means this expectation should be fulfilled.
    Third, at least Swiftsuspenders doesn't even need the [Inject] tag for
    constructors, so except for the reflection overhead, they're treated
    just the same as in your solution. Personally, I like to think of the
    built-in reflection support as a means to let me forego additional
    configuration, while still allowing me to take additional steps to
    make things faster if there's a need for that.


  3. Ondina D.F. closed this discussion on 27 Aug, 2012 10:38 AM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac