On Mar 10, 4:38 pm, peterk <[email protected]> wrote:
> Sorry if some redundant points are being raised here.. my lingering
> question in light of your post is regarding the variation in
> performance between itemAs' construction and itemBs' if both boil down
> to the same read behaviour on the datastore. To walk through lenza's
> code:
sorry, you're right. i misread the original code snippets. let me try
again.
> query = A.all().filter('intProperty', val).filter('date >=', date) # no reads
> at this point (?)
correct.
> itemAs = [itemA for itemA in query] # n disk seeks and reads where n =
> number of itemAs matching query (?)
roughly, yes. it's actually around n + n/20.
> itemBs = [itemA.typeB for itemA in itemAs] # n disk seeks and reads for n
> automatic dereferencing of itemA.typeB accesses (?)
correct.
> I'm guessing it's not that simple given the variation in performance
> between line 2 and line 3 reported by lenza. I'm gonna dig into your
> links tomorrow, so if an answer is in there, don't mind me! :)
the difference in performance is probably due to the RPC overhead
between the app and the datastore. the query only takes n/20 RPCs, one
for each result batch. the itemBs list comprehension takes n RPCs,
since it does a get() for each itemA.typeB. (that's due to the list
comprehension itself, which is in the app's code, so we can't collapse
those RPCs because we don't know they're coming ahead of time.)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en
-~----------~----~----~----~------~----~------~--~---
