Aaron and I had a brief discussion on IRC which may help:
07:28 < abentley> lifeless: injecting the permissions into the json
cache only helps at page load time.
07:28 < abentley> lifeless: We also need to evaluate the permissions
when we retrieve the objects over the web service.
07:28 < lifeless> abentley: that surprises me
07:28 < lifeless> abentley: can you help me understand why thats needed ?
07:30 < abentley> lifeless: A +sharing-details page may start with no
productseries associated with the sourcepackage.  When the user adds a
productseries, we need to know whether the user can change the branch
associated with the
                  productseries.
07:30 < lifeless> ok
07:30 < lifeless> adding a productseries is a named method right ?
07:30 < abentley> lifeless: yes.
07:31 < lifeless> so, I can suggest alternative implementations here
07:31 < lifeless> such as return the permissions with the result of the add
07:31 < lifeless> or do a separate lookup (though latency is a pain)
07:32 < abentley> lifeless: Yes, the reason I asked for them to be
properties was to avoid latency.
07:33 < lifeless> I understand - and sympathise - the problem though
is simply that lazr evaluates -all- properties every time
07:33 < lifeless> and permission checks are often very expensive
07:34 < abentley> lifeless: another option would be to use the json
cache and then provide a way to get an updated version of the json
cache.
07:34 < lifeless> abentley: that sounds like an interesting approach
07:34 < lifeless> because the json cache is tailored to the page AIUI
07:35 < abentley> lifeless: it would slay a lot of other latency
concerns I have, too.
07:36 < abentley> lifeless: The json cache is tailored per-view.
07:38 < lifeless> abentley: excellent!
07:38 < abentley> lifeless: well, except that it's scope-creepy.
07:40 < lifeless> in terms of feature delivery? I guess yes :(
07:41 < abentley> lifeless: Originally, we were just going to expose
Person.canWrite etc.  But that doesn't work because lazr.restful
doesn't support dynamic typing.
07:44 < lifeless> yeah, I saw the comment
07:44 < lifeless> its a shame, that would have been fairly pithy
07:44 < lifeless> would still have incurred a round trip for you
07:49 < lifeless> abentley: I don't want to leave you & your team hanging
07:50 < lifeless> abentley: would doing a separate round trip be
tolerable for the page? If so that seems like low development overhead
(change the property to a method)
07:52 < abentley> lifeless: We could certainly start there.
07:52 < abentley> lifeless: I have no idea what the performance of the
page is like on production.

07:53 < lifeless> only one way to find out
07:57 < abentley> lifeless: about 2 seconds.
07:57 < abentley> lifeless: for natty/bzrtools on qastaging
07:58 < lifeless> abentley: thats from choosing the productseries till
it shows up in the form, or the initial page load?
07:58 < abentley> lifeless: the former.
07:58 < lifeless> if you unset it
07:58 < lifeless> and set it again
07:58 < lifeless> it may be faster
07:59 < lifeless> qastaging only holds about 5% of the prod DB in RAM
07:59 < abentley> lifeless: I did actually.
07:59 < abentley> lifeless: that time's from the second run.
08:02 < lifeless> ah
08:02 < lifeless> doh !
08:03 < lifeless> possibly too many collections on the object being altered
08:03 < lifeless> lazr restful snapshots can be reallly expensive
08:04 < abentley> lifeless: You mean that the object in question has
too many collections, making snapshotting expensive?  You don't mean
altered collections?
08:04 < lifeless> right
08:05 < abentley> lifeless: It looks like one of the AJAX requests is
1.2 seconds, but I can't tell what the request was.
08:06 < lifeless> yeah
08:06 < lifeless> thats coming
08:06 < lifeless> using the chromium or firefox debug tools can give
better insight, if you know you need it
08:10 < abentley> lifeless: looks like setPackaging is the big delay,
and that's not exactly optional...
08:14 < lifeless> ah
08:14 < lifeless> I'm on a call now - sorry

From this I suggest the following options:
 - either returning the needed information from the set packaging call
(perhaps by using a custom call to do what you need). More dev time
needed, but no additional round trips and no overhead on API GET calls
for other code paths.
 - look into being able to get a fresh jsoncache from an API call
(variant of the first option) - specific to a view, will include all
the right data, easy to keep consistent with the scripts on a page
 - have a dedicated api call to check what you need - one extra
roundtrip, but nicely isolated and reusable

Cheers,
Rob