CAB and ObjectBuilder Performance
Considering this entry in my feed reader off of Steve Eichert’s blog…
In our experience at Xclaim, it’s not CAB or ObjectBuilder that is the bottleneck for your average business application, it’s caching tons of lookup data and metadata (we have ~4MB of just metadata) in the beginning of the application. Really any service you’ve declared with [Service] or register in the RootWorkItem in the AfterShellStarted (or whatever it’s called) method of your CAB application class is a potential time hog.
In these situations have to be careful that the data that you’re loading is coming in on another thread and the UI metaphors you’ve chosen drip feeding (the hypnotic AJAX ball). We’ve moved to “layer supertypes” (fancy way of saying “base class”) for our services that are easily refactored to multi-threading and supporting a asynchronous style. What’s cool about CAB is that it gives you the tools to build this kind of application… it provides a nice base, but you need to take it to the last mile.
In our big-assed CAB app (nearing release!) we’re optimizing there on these fronts. Reflection performance issues will be the absolute last bridge we cross when squeezing the last ounce of performance from the app. Though it’s good to know that there are tools in the Mobile Client Software Factory to bake in some of the attribute-based reflection mechanisms pre-compile.
[tags]CAB, Smart Clients, SCSF, Performance, Optimization, Architecture, Software Architecture, ObjectBuilder[/tags]
Post a Comment