Last post Apr 01, 2012 12:08 PM by ColinBlair
Mar 31, 2012 08:45 AM|dany0w|LINK
I just switched from using ria.js to upshot with my existing wcf ria services. The upshot api is great however I've noticed the time it takes from the ajax 'get' returning and upshot calling my refreshSuccess delegate has increased dramatically. It seems
like the code that takes care of assembling root results and included results into a single object graph is very slow. Maybe because this work is done up front in upshot where in ria.js it was deferred so I didn't really notice?
Here's my use case:
I'm using upshot on top of an existing wcf ria service layer that's already being consumed by a silverlight client. I need upshot to take care of converting root results and included results into a cohesive object graph that I can put in local storage.
I plan on using upshot's built in local storage provider when it's released. Much of the data I'm loading is static so I often don't need the change tracking/observables. One of the service calls I make using upshot returns an array of questions (the root
results) and their associated choices (included results). Here's the firebug profile for this service call returning ~400 root results and ~2000 included results (an extreme case to help identify the bottleneck):
The root results are of type "Question" with an numeric QuestionId. The included results are of type "Choice". The child "Choice" items have a "QuestionId" prop that links them back to the parent. The assembled object graph is an array of 400 or so questions,
each with approximately 5 choices.
The question/choice data is static, the only reason I'm using upshot here is so that I can reuse my existing wcf ria service. If I were to not use upshot I'd either have to roll my own object graph assembly or put a standard wcf service and dto layer on
top of the existing wcf ria service.
like upshot and knockout. As a test, I created a simple ".compat.js" file for upshot that returns poco objects and arrays instead of observables. This didn't improve the performance which leads me to believe the bottleneck is in upshot's code for assembling
the object graph.
Apr 01, 2012 12:08 PM|ColinBlair|LINK
One big difference between the DomainService and the DataController is that the DataController is going to be less efficient when doing an include where any of the included entities are shared by multiple root results. The DomainService would make sure that
no duplicate objects were sent to the client, the DataController is not doing that. That is coming from trying to be RESTful. Upshot.js itself is capable of doing the RIA Services type "receive loose unique entities and put them back together using the foreign
keys" type of communication so eventually I think we will see a DataController option which reenables that type of communication. Of course, since it is open source now we could just make that change ourselves.
To the bigger question however, no, nothing in SPA is fully optimized yet.